Instant Payments Fraud Controls: Real-Time Risk Without Breaking the 10-Second SLA

An instant payment is irrevocable the moment it settles. That single fact turns fraud scoring from a batch job you can afford to get slightly wrong into a real-time control that has to make its decision before the money is gone.

Since 9 October 2025, payment service providers in the euro area have had to offer customers the ability to send instant credit transfers in euro, not just receive them. The scheme’s defining constraint is speed: funds must be made available to the payee within ten seconds of the payment order being received, at any hour, on any day. There is no overnight window, no cut-off, no next-day recall as of right. Once the transfer clears, the fraud team is not preventing a loss; they are chasing one. Every fraud control you want to apply before the customer’s money leaves therefore has to fit inside that ten-second budget, and most of it inside a far smaller slice of it.

Why the batch model quietly breaks

Most incumbent fraud stacks were built for a world with slack in it. A transfer could sit in a queue for minutes or hours while rules ran, analysts reviewed alerts, and screening jobs completed. The architecture assumed you could always add one more check because latency was somebody else’s problem. Instant payments removes the slack. The ten-second scheme limit is not a target you aim for on a good day; it is a hard ceiling, and a sending PSP that misses it is in breach of the scheme, not merely slow.

The instinct is to lift the existing rules engine into the payment path and hope it keeps up. It will not, for a predictable reason: fraud logic that was written to be thorough was never written to be fast. Aggregations over ninety days of history, joins across half a dozen tables, a synchronous call to a third-party device-intelligence API — each of those is fine at rest and fatal inline. Put them in the critical path and your p99 latency, the one that matters, blows the budget for exactly the transactions you most want to inspect.

Split the work: inline versus asynchronous

The governing design decision is not which model to use. It is what runs inside the window and what runs outside it. Draw that line deliberately and the rest follows.

Inline, on the critical path, with a hard deadline: a lookup of precomputed features from a low-latency store, a single fast model inference, and a deterministic policy layer that turns the score into allow, hold or reject. Nothing here computes anything expensive. The features have already been calculated; the inline step only reads them.

Asynchronous, off the critical path: the heavy analysis. Graph queries that trace mule networks, behavioural models over long histories, feature recomputation, case creation. This work still happens — it is where a great deal of the actual detection lives — but it informs the next payment, not the one in flight. You accept that the current transaction is scored on features that are seconds or minutes stale, because the alternative is scoring nothing in time.

This is the same architectural move the regulation itself forces elsewhere. Sanctions screening under the Instant Payments Regulation shifts from screening every transaction against the lists to screening your customer base against updated lists at least daily — the check moves out of the payment path by design. We wrote about that re-architecture in re-architecting sanctions screening around daily lists rather than per-transaction calls, and the fraud pattern mirrors it: precompute what you can, read fast inline, and push the slow work to where the clock is not running.

Budgeting the ten seconds

Ten seconds sounds generous until you account for everyone who needs a share of it. The clearing and settlement mechanism, the receiving PSP’s own processing, network hops and the Verification of Payee check all consume part of it before your fraud logic gets a turn. Verification of Payee — the IBAN-name match the sender sees before confirming — is itself an inline, pre-execution control with its own tight latency target, covered in architecting Verification of Payee for sub-five-second name matching. Treat the ten seconds as a shared budget, allocate your fraud step a fixed slice of it — a low single-digit number of hundreds of milliseconds is a realistic working figure — and enforce that slice as a deadline, not an aspiration.

Enforcing it means every inline call carries a timeout derived from the time remaining, and every timeout has a defined fallback: fail to an asynchronous review, hold for step-up authentication, or reject, according to your risk appetite. What you never do is block the settlement message waiting for a slow dependency. The deadline owns the decision.

# Real-time fraud scoring inside the SCT Inst window.
# Our slice of the ten-second scheme limit for inline checks.
# Everything must resolve or fall back by the deadline --
# never block the settlement message on a slow dependency.

import time

INLINE_BUDGET_MS = 400      # this PSP's share of the ten-second SLA
FEATURE_TIMEOUT_MS = 120    # per low-latency feature lookup
SCORE_TIMEOUT_MS = 40       # model inference at p99

def score_payment(order):
    start = time.monotonic()
    def remaining_ms():
        return INLINE_BUDGET_MS - (time.monotonic() - start) * 1000

    # 1. Read PRECOMPUTED features -- never aggregate inline.
    try:
        features = feature_store.get_many(
            keys=order.feature_keys(),          # payer, payee IBAN, device
            timeout_ms=min(FEATURE_TIMEOUT_MS, remaining_ms()),
        )
    except TimeoutError:
        return decision("review_async", "feature_timeout")

    # 2. One small model, sized to meet SCORE_TIMEOUT_MS.
    try:
        risk = model.predict(
            features, timeout_ms=min(SCORE_TIMEOUT_MS, remaining_ms()))
    except TimeoutError:
        return decision("review_async", "score_timeout")

    # 3. Deterministic policy -- cheap, no I/O.
    if risk >= HARD_BLOCK:
        return decision("reject", "risk_hard_block")
    if risk >= HOLD and remaining_ms() > 0:
        return decision("hold_for_step_up", "risk_elevated")

    # 4. Heavy analysis is queued, not awaited.
    #    It informs the NEXT payment, not this one.
    async_queue.publish(order, features, risk)
    return decision("allow", "within_appetite")

Headroom is the control, not the model

The temptation is to judge this architecture by the accuracy of the model. The more useful measure is what happens at peak. Instant payments arrive at volumes and in bursts your batch stack never saw, and your fraud step has to hold its latency budget at the ninety-ninth percentile under that load, not at the median in a quiet test. If the feature store’s tail latency degrades when traffic triples, your fraud control degrades with it, and it does so precisely when fraud attempts cluster. Capacity headroom in the low-latency read path is therefore a fraud control in its own right. Load-test the inline path at multiples of forecast peak, measure the tail rather than the average, and size the store and the model so that the deadline is met by margin, not by luck.

Firms that only receive instant payments today have a little longer before the send obligation and its fraud exposure land on them — euro-area electronic-money and payment institutions face their own dates, set out in the EMI and PI instant-payments deadline of 9 April 2027. That is time to design the split properly, not time to defer it.

The uncomfortable truth is that instant payments do not make fraud detection harder to model. They make it harder to afford in time. Get the inline-versus-asynchronous line right and a modest model inside the budget beats a brilliant one that arrives a second too late, because at a second too late the money has already gone and the model is writing history.