Designing fraud checks that finish before the sale

Designing fraud checks that finish before the sale

We noticed the awkward moment straight away: the buyer had decided to proceed, the dealer was ready to commit, and the fraud check was still running.

If the result arrives too late, the customer waits and the dealer loses confidence in the process. Let the transaction proceed early, though, and the check hasn’t protected anything. Block the wrong transaction and a legitimate sale fails.

So the gate has to close before the transaction completes.

That left us with three practical questions. Where does the check sit? How long can it take? And what evidence does it leave behind?

Putting the check in the transaction

We model the fraud check as a synchronous control point. It receives the transaction context, runs its checks and returns a decision within a time budget the transaction can tolerate.

Three things shape how that gate behaves:

• Latency: the time between submitting the transaction and receiving a decision.
• Coverage: the signals, documents and identity evidence included in the check.
• Auditability: the persistent record available for later review, disputes or compliance.

They pull against each other. Adding more sources may improve coverage, but it may also make the check slower. Set a tighter deadline and the gate may have to return a partial result, or say explicitly that it couldn’t determine an outcome.

Whatever happens, the audit record still needs to explain it.

Giving the gate a real deadline

There isn’t one acceptable wait for every transaction. A finance application may tolerate more time than signing at a desk. A digital retail flow may tolerate less.

We need to state that time budget clearly and design the gate around it. “As fast as possible” sounds reasonable, but it isn’t a useful contract.

What happens when the check can’t finish in time?

It should return an explicit outcome. A late response isn’t a pass. A silent timeout isn’t a block. Treating either one that way hides a transaction decision inside failure behaviour.

That distinction matters because timeout policy is transaction policy. The dealer needs to know whether to proceed, stop or move the case into another process.

Drawing the boundary around the check

A fraud check may depend on identity data, documents, vehicle history or fraud registries. Each external source adds time and another way for the check to fail.

The boundary needs to be clear. Sources required before the decision belong inside the synchronous gate. Sources that can finish later are asynchronous and may trigger a downstream action.

Mixing those two groups creates ambiguity. Some checks can block the transaction and others can’t, but the difference is hidden.

For every decision, the gate should record which sources it consulted, which responded, and which were skipped or timed out. That makes partial coverage visible instead of letting it look like a complete check.

Keeping enough evidence to explain the result

A decision without a persistent record can’t be examined later. If someone disputes the outcome, the dealer, buyer or regulator needs to see what was checked, what came back and why the gate responded as it did.

The audit record should capture:

• the transaction context at decision time
• the signals consulted
• the source responses, including missing responses
• the decision returned
• the timestamp

Without that record, the result is only an assertion.

There’s also a limit to what this framework can tell us. It can describe the constraints, but it can’t show whether a particular product meets its requirements. That assessment needs attributed documentation of its inputs and outputs, observed latency under real transaction loads, details of the signals and their freshness, and the audit format and retention policy. Engineering testimony or observed traces may be needed too.

Until that evidence is available, we can’t judge the implementation. The question we’re left with is the one that matters at the point of sale: did the gate make a timely, explainable decision before the transaction passed beyond it?