Initially, when an organization deploys a real-time fraud prevention system, at least two responses are inherently required - Approve and Decline. If the monitored event (funds transfer, loan application, invoice payment request, consultation with family doctor) is not suspicious enough, the final assessment will tag the transaction as non-fraudulent, and a 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 there is no human involvement in the fraud assessment decision. And this is extremely helpful as with this approach, all transactions are assessed within an extremely short SLA (usually less than 100ms). This process, though, applies a clear bifurcation - fraudulent or non-fraudulent outcome.

The above diagram depicts the simplified high-level interaction flow between channels and 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 is happening seamlessly and in a fully automatic fashion.

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 the new car, deposit for a new house, car-fix after an accident, unexpected travel due to family reasons and many other). 

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

Some transactions have to be assessed and decided on the spot. Still, some can be "paused" in case certain non-negligible suspicious patterns show up but are not 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. Though 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 is putting an extra action on the customer, so though the message flow is interrupted and changes to a non-straight-through process, there is no impact on fraud analysts or fraud operations.

The other option is Hold or Suspend. This option is similar to step-up, though the release mechanism lies on the fraud analyst and not on the customer as it was 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 is an actual fraud attempt. Based on the final decision, the analyst will release the transaction for further processing or declines it. Similarly to step-up, also SLA comes into play and in case the analyst within the predefined SLA does not attend the transaction, the pre-configured decision will take place. Most commonly, such transaction is declined, but this is up to the fraud business unit to decide on 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 additional two options in the initial phase of the project, as it would delay the initial go-live. On this spot, I would refer you to my other blog post - Don't trade the go-live date for more functionality.

One last point remains unanswered: Where do the two new options fit within the scale of fraud risk?

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