Approve or Decline - are these all our options?

When an organization deploys a real-time fraud prevention system, it inherently requires at least two responses: Approve and Decline. If the monitored event (funds transfer, loan application, invoice payment request, consultation with a family doctor) is not suspicious enough, the final assessment will tag the transaction as non-fraudulent, and the decision will be Approved. If the transaction is highly suspicious and, after running the applicable assessment rules, we are almost certain it's a fraud, the decision will be Declined.

These two responses are managed within the Straight-through process (STP), meaning no human is involved in the fraud assessment decision. This is extremely helpful, as this approach assesses all transactions within a very short SLA (usually less than 100ms). This process, however, applies a clear bifurcation: fraudulent or non-fraudulent outcome.

The diagram above depicts the simplified, high-level interaction flow between channels and the Enterprise Fraud Management system. Transactions (financial as well as non-financial) originate in the channels depicted on the leftmost side of the diagram. These are transferred (via the Message Orchestration layer - which is just a generic term for various technologies that could be used to route and translate the message) to the Fraud Management system, where they are assessed for fraud risk.

At the end of the process, the assessment completes with a final response - Approve or Decline - which is sent back to the Message Orchestration layer. Based on the fraud assessment decision, the Message Orchestration layer follows the pre-configured flow. All of this happens seamlessly and fully automatically.

Introduction of the non-STP decisions

In the real world - and especially after deployment of the new system - there are often events that do trigger some anomaly detection rules (as no customer stays within the usual patterns all the time, there are always some unusual transactions - like the purchase of a new car, a deposit for a new house, a car fix after an accident, unexpected travel due to family reasons, and many others).

Also, when we consider the need for an immediate assessment, not all events require an on-the-spot decision. For example, a home loan application submitted by a customer can take hours, or even a few days, to evaluate for potential signs of fraud, unlike a POS purchase at our favorite coffee shop.

Some transactions have to be assessed and decided on the spot. Still, some can be "paused" if certain non-negligible suspicious patterns show up but aren't serious enough to decline the transaction on the spot.

The first option that can be used is step-up, which will alert the Message Orchestration layer to break the current flow, "pause" the message (e.g., by dropping the message into a Message queue), and initiate OTP or another step-up authentication method to double-check that the transaction was initiated by the actual customer and not a fraudster. Suppose the customer successfully passes the OTP or the other authentication method. In that case, the transaction is released ("picked up" from the queue and pushed to the corresponding system) to continue its journey. However, if the customer doesn't provide the OTP or the transaction reaches its pre-defined SLA in the "pause" mode, it is declined.

Step-up mode adds an extra action for the customer, so although the message flow is interrupted and becomes a non-straight-through process, it has no impact on fraud analysts or fraud operations.

The other option is Hold or Suspend. This option is similar to step-up, but the release mechanism lies with the fraud analyst, not the customer, as it is in step-up.

A transaction put on hold or suspended waits for the analyst to release it. As part of the high-priority triage process, the analyst usually reviews the transaction details and the customer's history to decide whether the customer initiated the transaction or it is an actual fraud attempt. Based on the final decision, the analyst releases the transaction for further processing or declines it. Similar to step-up, also SLA comes into play. If the analyst does not attend to the transaction, the pre-configured decision will take place. Most commonly, the transaction is declined, but the fraud business unit decides the appropriate action.

Comparing the two diagrams - one with only Approve & Decline and the other with additional Step-Up & Hold/Suspend - we can observe that the main changes are linked to the Message Orchestration layer, where additional functionality has to be implemented or configured. This is also usually a reason why it is uncommon to deploy these two additional options in the initial phase of the project, as it would delay the initial go-live. On this point, I would refer you to my other blog post - Don't trade the go-live date for more functionality.

Where do the two new options fit within the scale of fraud risk?

It's quite simple, as shown in the diagram above. Low fraud risk results in an Approve decision, followed by a Step-up, where the customer must provide additional confirmation (usually OTP or token) for the transaction to be processed. If risk increases and we have a hold/suspend capability, we could put the transaction on Hold and wait for the fraud analyst to make the final decision. This, of course, applies only to those transactions that can be put on hold. The last option is Decline, which means the fraud risk reached the predefined threshold beyond which the transaction is considered fraudulent.