Designing Event Monitoring Rules That Stay Explainable

Explainable fraud decisions start with consistent event data. A rule engine can only produce useful evidence when every login, payment, signup, and account update carries stable identifiers and domain-specific metadata.

What to Send

• Use consistent eventName values such as user.login or payment.completed.
• Send customer, device, IP, session, and amount context on the first API call.
• Keep rule names human-readable because they appear in review workflows.
• Reserve BLOCK for high-confidence cases and REVIEW for signals that need human context.

{
  "eventName": "payment.completed",
  "customer": { "externalId": "user_123456" },
  "device": { "externalId": "device_abc123" },
  "ip": "203.0.113.42",
  "sessionId": "session_xyz789",
  "metadata": { "amount": 500, "currency": "SAR" }
}

Make Decisions Auditable

Store correlationIds.eventId beside your product transaction id. That gives support, risk, and engineering a shared key when a customer asks why a payment was reviewed.

Read the event monitoring guide for the complete event-to-decision flow.