Anticipating the RFI: a thought experiment on a familiar bottleneck

Every working day, thousands of cross-border payments stop moving because one bank wants something from another. A sanctions screening hit. An AML alert. A fraud rule that fired. The receiving institution opens a Request For Information, the originating institution scrambles to assemble an answer, and somewhere a customer waits - sometimes hours, sometimes weeks.

It’s worth asking whether that has to be the shape of the work.

The questions are rarely new

Map the actual content of RFIs and a pattern emerges: there are roughly three families, each with a tight, recurring set of questions that don’t vary much from one transaction or bank to the next.

Sanctions screening alerts are almost entirely about entity resolution. Is this John Y. the same John Y. on the OFAC list? The questions follow predictably - full legal name and aliases, date and place of birth, nationality, address, identifiers - and for legal entities the analogous structural fields. The screening world’s open secret is that the overwhelming majority of these alerts are false positives, and the work to clear them is mostly clerical.

AML alerts are about purpose and provenance. Where is the money coming from, where is it going, why? What is the relationship between originator and beneficiary? Does the geography fit the customer’s stated business? Are there typology red flags warranting escalation? Can the originating bank produce supporting documents - invoices, contracts, shipping papers?

Fraud holds are about authentication, behavioural fit, and destination quality. Did the customer actually authorise this? Was there a recent profile change just before the transaction fired? Does the amount, frequency, channel, and timing line up with normal behaviour? Is the destination known to attract complaints from other senders?

If you’ve worked an investigations desk, none of this is news. What’s interesting is what could follow from the observation that it’s so consistent.

The economics of waiting

Financial crime compliance is now a roughly $206 billion global line item, with the U.S. and Canada alone spending around $61 billion a year. The Wolfsberg Group’s best-practice guidance for correspondent-banking RFIs treats a response window of 10 to 30 business days as the industry norm - that’s the cycle time compliance teams plan around, and the cycle time customers wait through.

That waiting carries costs that don’t show up cleanly on a P&L: working capital frozen for the customer, analyst hours consumed by aging queues, correspondent relationships quietly de-risked when a corridor becomes too RFI-heavy, and false-positive fatigue eroding the quality of real investigations.

Reducing the volume of alerts is hard - most of it is regulatory minimum. Reducing the cycle time per alert is a different problem, and arguably a more tractable one.

$206B

Annual global financial crime compliance spend

$61B

U.S. + Canada share of that spend

10-30

Business days, Wolfsberg-norm RFI response window

Minutes

Cycle time when the answer is pre-assembled

What if the answer arrived before the question?

Here’s an inversion worth turning over. If the questions are largely predictable per scenario, and most of the data needed to answer them already exists somewhere inside the originating bank, then in principle the work of assembling an answer could happen before anyone asks.

Imagine a different version of the same flow. The originating bank’s systems flag a small set of risk markers on an outbound payment - a higher-risk jurisdiction, an outlier amount, a counterparty name that historically generates screening hits - and quietly assemble a structured evidence packet against the questions a competent investigator would tend to ask. The packet travels with the payment itself as enriched metadata, so the receiving bank already holds the answer the moment its own systems raise the question.

Today

10-30 business days

Payment → RFI → manual assembly → response → cleared

Anticipated

Minutes

Payment → RFI → packet pre-built → cleared

The infrastructure for this isn’t conceptual. ISO 20022 has already widened the data envelope of cross-border payments dramatically. What’s less developed is the operational layer that would turn a bank’s scattered internal information - KYC files, transaction history, customer documents, internal risk ratings - into something a counterparty can ingest at speed.

The hurdles that come with it

Three things make this harder than the framing suggests.

Data sharing rules. Privacy and bank secrecy regimes constrain what one institution can pre-share with another. Section 314(b) in the U.S. and the EU AML reforms cover part of the institution-to-institution channel, and customer consent could plausibly fill much of the rest.

Format standardisation. A pre-prepared packet only saves time if the receiving bank can ingest it without re-keying. That implies some level of agreement on schemas at the granularity investigators actually need.

Willingness. Sharing more makes some institutions cautious - for liability reasons, and because it changes the implicit posture between sender and receiver. A reciprocity model, and probably some regulatory blessing, would likely be needed before this scaled.

Directions that could chip at all of this

A few patterns seem worth watching.

Pre-preparation without pre-sharing. Possibly the most interesting near-term direction: doing the assembly work in advance even when the data still travels reactively. The bank waits for the RFI to land before transmitting anything - but when it lands, the answer is already built and response time collapses from days to minutes. This sidesteps the data-sharing constraint entirely; the work that took the time was never the transmission, it was the assembly.

Customer-mediated consent. Customer consent is a clean legal basis for sharing personal data in almost every privacy regime. A scoped consent at onboarding could cover the everyday case; a just-in-time prompt at payment initiation, modelled on SCA, could cover higher-risk transactions. The customer trades a small consent friction for a payment that doesn’t sit in limbo, and gains visibility into compliance traffic that today happens largely behind their back.

Riding existing standards rather than waiting for new ones. ISO 20022, common KYC document formats, beneficial-ownership schemas, and sanctions-screening data models are already standard enough to assemble against. The constraint may be less about waiting for a new global RFI standard than about operationalising the ones that exist.

A different framing of the work

The default framing today is an inbox problem: alerts arrive, queues grow, analysts answer. A pre-emptive framing would treat the same work more like a manufacturing problem - the questions are known, the inputs are mostly inside the building, the output is a structured packet. Whether the industry moves in that direction, and how quickly, is genuinely open.

What does seem clear is that the economics of compliance and the cost of friction-driven customer attrition are pointing the same way. Anticipating the RFI may or may not turn out to be the dominant pattern, but it’s a useful lens for thinking about what compliance operations could look like if cycle time, rather than alert volume, became the variable the industry optimised for.

---

Auditale’s investigation agents are built around exactly this kind of pre-emptive assembly - the unglamorous, data-heavy work that determines whether an investigation takes minutes or weeks. Talk to us.