One decision id, three places

Why one id

When a payment is held, three teams need the same answer at the same moment. The app has to show the customer the right next step. The fraud team has to see why, in the system it already works in. And months later, a complaint or an auditor will ask what was decided and on what grounds. If each of those reads a different record, they will disagree.

So every DeepID decision carries one id, and that id is the same in the app, in the event your FRM receives and in the decision log.

The app first

Your app calls once at each moment, before the action takes effect: sign-up, login, a new phone or SIM, a new payee, the payment. The decision comes back with an action, its reason codes, the message for the customer and the policy version that made it. The app acts on it at once.

Then your FRM

The same decision reaches your FRM, case manager or SIEM as an event, with the same reasons and, when a person needs to act, a queue such as a call-back. Your FRM keeps its own rules, queues and cases. What it gains are the signals it never received before: the call, the shared screen, the dictated typing, the payee’s links.

Then the log

The decision log keeps every decision with its reasons, the message as the customer read it and the policy version that applied. Policies are versioned, so you can show what rule applied and when.

What we agree first

Event names and fields are illustrative until they are agreed in the sandbox with your platform team, together with how events are delivered, signed and retried. The webhooks reference shows the event field by field.