ShanverseCập nhật 11 phút đọc— lượt xemĐang tải lượt xem
Fraud Detection
Message Queue
Payment Systems
Bài toán Impossible Travel
Giả sử cùng một tài khoản có hai giao dịch:
Khoảng cách đường chim bay xấp xỉ hơn 1.100 km. Vận tốc cần thiết vượt xa khả năng di chuyển thực tế, nên đây là impossible-travel signal.
Nhưng rule đơn giản distance > X && time < 5 minutes có thể báo sai khi:
Event đến Kafka trễ hoặc sai thứ tự.
Provider gửi duplicate.
Vị trí lấy từ IP/VPN có độ chính xác thấp.
Giao dịch đầu bị reversed/declined nhưng vẫn đi vào stream.
Tài khoản doanh nghiệp có nhiều thẻ phụ hoặc người được ủy quyền.
Một giao dịch dùng vị trí merchant headquarters thay vì điểm chấp nhận thực.
Bình luận
Clock của nguồn dữ liệu sai.
Vì vậy cần stateful stream processing, event-time semantics và risk decision nhiều tín hiệu.
Kiến trúc tổng thể
Mermaid
Loading diagram…
Kafka là durable event backbone. Fraud Engine có thể dùng Kafka Streams, Flink hoặc một stream processor khác; bài này minh họa bằng Kafka Streams.
Contract của sự kiện giao dịch
Các nguyên tắc:
eventId và transactionId ổn định để deduplicate.
Tách occurredAt khỏi ingestedAt.
Số tiền dùng integer minor units, không dùng floating point.
Location có source và accuracyMeters.
Pseudonymize account/card IDs trên analytics topics.
Schema versioned bằng Avro/Protobuf/JSON Schema và compatibility policy.
Không đưa PAN, CVV, PIN, access token hoặc PII không cần thiết vào topic.
Transactional Outbox thay cho dual write
Không thực hiện:
Nếu bước 2 thất bại, core banking có giao dịch nhưng fraud stream không thấy. Thay vào đó, ghi transaction và outbox trong cùng database transaction; CDC/outbox publisher đưa event lên Kafka và retry an toàn.
Duplicate vẫn có thể xuất hiện, nên consumer phải idempotent. “At least once” không có nghĩa xử lý side effect nhiều lần.
Chọn partition key
Impossible travel cần nhìn thấy lịch sử theo cùng thực thể theo đúng thứ tự tương đối. Chọn key theo domain:
accountId: phát hiện hành vi toàn tài khoản.
cardId: phù hợp card-present và thẻ phụ.
customerId: hợp nhất nhiều account nhưng tăng skew và yêu cầu privacy chặt hơn.
Kafka chỉ bảo đảm ordering trong một partition. Nếu cùng khách bị partition theo transactionId, hai giao dịch có thể đến hai processor khác nhau và không chia sẻ state.
Với hotspot account, cần theo dõi partition skew. Không thay key tùy tiện giữa các producer.
Event time, processing time và late events
Event time: thời điểm giao dịch thực sự xảy ra tại nguồn.
Ingestion time: lúc Kafka nhận event.
Processing time: lúc Fraud Engine xử lý.
Impossible travel phải dựa trên event time. Nếu dùng processing time, network delay có thể biến hai giao dịch cách 30 phút thành 10 giây hoặc đảo thứ tự.
Kafka Streams cho phép window và grace period để nhận out-of-order records. Event đến sau grace cần đi vào late-event topic hoặc reconciliation pipeline thay vì biến mất không quan sát.
Các giá trị chỉ là ví dụ. Production chọn theo latency distribution, SLA và chi phí state.
Tính khoảng cách và vận tốc
Với hai điểm latitude/longitude, có thể dùng Haversine để ước lượng khoảng cách trên mặt cầu:
Ngoài stream, PostGIS ST_Distance trên type geography có thể tính geodesic distance theo mét. Không dùng Euclidean distance trực tiếp trên độ latitude/longitude.
Đừng chỉ dùng một ngưỡng vận tốc
Feature hữu ích:
distance_km và required_speed_kmh.
minutes_since_previous_authorised_transaction.
location_source và accuracy.
Cặp channel: ATM→ATM, POS→ATM, mobile→ATM.
Card/device/token có giống nhau không.
Giao dịch trước có approved, reversed hay declined.
Country/border change.
Amount, ATM cash-out ratio và daily velocity.
New device, SIM change hoặc credential recovery gần đây.
Beneficiary/merchant novelty.
Lịch sử di chuyển bình thường của khách.
Ví dụ policy:
Rule này tạo signal/score, không nhất thiết tự decline.
Stateful processing với Kafka Streams
Mỗi account/card cần state các giao dịch gần nhất:
Mermaid
Loading diagram…
Pseudo-code:
Transformer:
Deduplicate eventId.
Load recent state by key.
Insert event sorted by occurredAt within bounded history.
Compare with relevant previous/next events.
Produce feature vector, rule hits và risk score.
Persist bounded state.
Emit deterministic decisionId.
Chỉ lưu “last event” có thể sai khi event đến muộn. Nên giữ một deque/time-indexed state trong window đủ nhỏ và recompute cặp liên quan.
Exactly-once: phạm vi phải hiểu đúng
Kafka Streams exactly-once có thể atomic offset commit, state-store update và output-to-Kafka. Nó không làm cho REST call khóa thẻ, gửi SMS hoặc tạo case ở hệ thống ngoài trở thành exactly-once.
External actions cần:
Deterministic decisionId/actionId.
Unique constraint ở Action Service.
Transactional inbox/outbox.
Idempotent API.
Retry với backoff và dead-letter/exception queue.
Reconciliation giữa quyết định và hành động thực tế.
Không acknowledge action trước khi lưu trạng thái bền vững.
Rules, ML và graph nên phối hợp
Rules
Nhanh, giải thích được và phù hợp pattern rõ như impossible travel, excessive velocity hoặc blacklisted terminal. Nhược điểm: dễ cứng, nhiều false positive và attacker có thể né ngưỡng.
Machine Learning
Kết hợp hàng chục/hàng trăm feature để học pattern phi tuyến. Cần chống training-serving skew, model drift, label delay và bias.
Graph analytics
Phát hiện thiết bị, merchant, beneficiary, địa chỉ hoặc tài khoản dùng chung bất thường. Hữu ích với fraud ring nhưng thường có latency/cost khác.
Mô hình production thường là:
Rule engine vẫn cần ngay cả khi có ML để áp hard controls, policy và fallback khi model unavailable.
Feature store online và offline
Các feature real-time:
Count/sum 1m, 5m, 1h, 24h.
Unique ATM/merchant/country trong window.
Time since last cash withdrawal.
Distance/speed from previous trusted location.
Failed auth/OTP/device events gần đây.
Offline training phải tái tạo feature theo event time tại thời điểm quyết định, không dùng dữ liệu tương lai. Nếu training query thấy chargeback xảy ra sau giao dịch khi tính feature của giao dịch đó, model bị data leakage.
Version feature definitions, model, rules và thresholds trong mỗi decision để replay/audit.
Từ risk score đến action
Chỉ là ví dụ. Action phải xét channel và khả năng can thiệp:
ATM authorization cần quyết định trong latency budget rất thấp.
Giao dịch đã posted chỉ có thể hold follow-up, alert hoặc initiate recovery/reversal theo quy trình.
Mobile transfer có thể yêu cầu passkey/Smart OTP transaction signing.
Case Management cho analyst xem reason codes và evidence tối thiểu.
Không hiển thị rule chi tiết cho attacker. Khách hàng cần thông báo đủ rõ để xác nhận giao dịch nhưng không lộ logic chống gian lận.
Xử lý duplicate, correction và reversal
Deduplicate theo eventId, nhưng hai giao dịch thật khác nhau không được gộp chỉ vì cùng amount/location.
Correction là event mới tham chiếu event gốc.
Reversal không xóa giao dịch; nó thay đổi effect theo event riêng.
Khi late correction thay đổi feature, có thể phát FraudDecisionUpdated thay vì sửa lịch sử im lặng.
Quyết định đã dẫn đến decline không thể “un-decline” quá khứ, nhưng cần cập nhật case và labels.
Event log và decision log phải immutable/auditable; projection có thể cập nhật.
False positive và các edge cases
Chuyến bay không tạo khoảng cách 1.000 km trong 5 phút, nhưng time window dài hơn phải xét airport/route/timezone.
IP geolocation không đủ chính xác để auto-decline.
ATM/POS terminal coordinates có thể sai hoặc bị cấu hình theo trụ sở.
Digital wallet token có thể được dùng trên thiết bị khác theo policy hợp lệ.
Joint/business account có nhiều người dùng.
Batch posting không phản ánh thời điểm mua thực tế.
Offline terminal upload muộn.
Test/internal transactions phải được nhận diện nhưng không bypass production tùy tiện.
Mỗi location nên có trust level; chỉ pair hai vị trí đáng tin cậy mới tạo hard signal.
Security và privacy của fraud platform
TLS/mTLS và ACL cho producer/consumer/topic.
Service account riêng, least privilege và secret rotation.
Encrypt broker disks, state stores, backups và data lake.
Tokenize account/card IDs; tách vault mapping.
Topic retention tối thiểu theo mục đích/pháp luật.
Không cho analyst export raw PII mặc định.
Audit rule/model change và case access.
Schema validation chống poison messages.
Quarantine malformed event; không để một record làm chết partition.
Chống insider thay threshold hoặc whitelist bằng maker-checker.
Fraud data bản thân có thể bị attacker lợi dụng để suy ra rule và hành vi khách hàng.
Observability và SLO
Theo dõi:
End-to-end decision latency p50/p95/p99.
Consumer lag theo partition.
Event-time lateness và late-drop rate.
State-store size, restore time và changelog health.
Duplicate, invalid-schema và DLQ volume.
Rule hit rate, alert rate, step-up và decline rate.
Precision, recall, false-positive rate và fraud loss.
Model drift/feature drift.
Action delivery mismatch.
Chỉ tối ưu accuracy là chưa đủ. Hệ thống fraud cần cân bằng fraud loss, customer friction, analyst capacity và latency.
Replay và backfill an toàn
Kafka cho phép replay để kiểm thử rule/model mới, nhưng không được tái thực thi action production.
Tách decision simulation topic khỏi live action topic.
Gắn mode: SHADOW/REPLAY/LIVE.
Dùng output namespace mới.
Freeze hoặc version reference data.
So sánh decisions với labels và baseline.
Không gửi notification/decline từ replay consumer.
Shadow mode là bước quan trọng trước khi tăng quyền cho rule/model mới.
Test matrix production
Hai ATM cách 1.100 km trong 5 phút.
Duplicate event 10 lần.
Event thứ hai đến trước event thứ nhất.
Event đến sau grace period.
Giao dịch đầu bị reversal.
IP geo sai nhưng ATM geo đúng.
Joint account hoặc nhiều supplementary cards.
Partition rebalance và state-store restore.
Processor crash sau output trước offset commit.
Action Service timeout sau khi đã khóa thẻ.
Schema evolution tương thích/không tương thích.
Model service timeout và fallback rule.
Replay không gây action thật.
Peak traffic, hot key và broker degradation.
Checklist triển khai
Core transaction và outbox được commit atomic.
Partition key bảo đảm state theo account/card.
Event schema có event time, ingestion time, location source/accuracy.
Window/grace/retention được chọn từ dữ liệu latency thực.
Deduplication không xóa hai giao dịch thật.
Impossible travel dùng distance + delta time + location trust.
Rules tạo reason codes và phối hợp với ML/graph.
Kafka exactly-once không bị nhầm với external exactly-once.
Action Service idempotent và có reconciliation.
Decision, feature, rule và model đều versioned.
Privacy, ACL, encryption và audit hoạt động.
Có shadow, replay và rollback trước production.
Kết luận
Impossible travel là ví dụ điển hình cho stateful real-time fraud detection: phải đặt các event cùng thực thể vào một partition, xử lý theo event time, lưu history có giới hạn và tính vận tốc từ vị trí đủ tin cậy.
Kafka giúp vận chuyển, lưu bền và xử lý stream; nó không tự quyết định gian lận. Chất lượng hệ thống đến từ event contract, state, geospatial logic, rules/ML, idempotent actions, feedback labels và quản trị false positive.
Mục lục(24)
Codeplain text
1T1: ATM withdrawal, Hanoi, 10:00:002T2: ATM withdrawal, Ho Chi Minh City, 10:05:00
Codeplain text
11. Commit giao dịch vào database22. Publish Kafka
Hướng dẫn xử lý transaction storm trong flash sale và quyết toán lương với RabbitMQ/Kafka, rate limiting, backpressure, circuit breaker, load shedding, idempotency và capacity planning.
Hướng dẫn kiến trúc eKYC với NFC đọc chip căn cước, OCR giấy tờ, face matching, liveness/PAD, kiểm tra tính toàn vẹn, bảo vệ dữ liệu sinh trắc học và vận hành production.
Hướng dẫn xây hệ thống điểm danh bằng QR động hoặc nhận diện khuôn mặt, tập trung chống gian lận, liveness, quyền riêng tư, audit và triển khai an toàn.
