RFI Handling: What Happens While Your Case Waits on Someone Else

An RFI, a request for information, is the step where your team stops and asks someone outside it for something: a customer who has to resend a proof of address that expired, or a regulator who wants a documented answer about a decision you already made. Until the reply arrives, the case does not move.

Every other step in a compliance flow is work your team controls and can schedule. The RFI is the one that leaves the building.

The RFI is the step your team cannot schedule

Screening runs when you call it. Risk scoring runs on data you already hold. A reviewer works the queue in the order you set. All of it is yours to plan.

Then the case reaches the point where the answer is in someone else's hands, and your team's job changes from doing the work to tracking the absence of it. That is a different job, and most ops stacks were never built for it.

The cost shows up in two places. A customer waits while their payment sits held. And your team carries a growing set of open requests that nothing in particular is watching.

Two shapes: a held payment, and a missing document

An RFI can start almost anywhere a decision needs something your team does not hold:

→ a sanctions or AML hit that is not clean enough to clear and not strong enough to fail

→ a fraud case where the reporter has to supply the rest before an analyst can close it

→ an onboarding file, or a periodic review, where a proof of activity or address never arrived or has expired

→ a regulator or a sponsor bank asking you to justify a decision you already made

The triggers differ, the counterparties differ, and the team holding the file differs. Across the fintech ops teams we work with, all of them land in one of two shapes.

The held payment. A screening engine flags a transaction and the money stops. Your compliance team reviews the context, and when the file does not support a decision either way, they open a request for information. The payment stays held until the answer lands.

The missing document. A proof of activity or a proof of address is absent or expired. There is no single transaction waiting, but the account is out of compliance from the day the alert fires, and it stays that way until someone sends a file.

The two look different on the surface and behave identically underneath. A case opens, work stops, a clock starts, and something has to happen when the clock runs out.

The request leaves the case, and the answer comes back somewhere else

Here is where it breaks in practice.

The alert is produced in one system. An operator reads it and writes the request in another, the support tool, because that is where the customer conversation lives. The customer replies to the ticket. The ticket is resolved. And the case that started all of it has no idea any of this happened, because nothing wrote back to it.

So your team rebuilds the link by hand. Someone checks the ticket queue against the alert list and works out which cases are still open and which quietly resolved last Tuesday. That reconciliation is the real cost of an RFI, and it scales with volume in a way the asking never does.

Running the request from the case closes that gap at the source. The RFI goes out through your support tool, and the reply lands back on the case that raised it, with the document attached where the reviewer will look for it.

What the clock does when nobody answers

A deadline with nothing behind it is a note in a spreadsheet. The teams that run this well give the clock consequences, written into the process rather than into someone's memory.

The document chase is the clearest version. The request goes out. At a fixed delay with no response, the account is blocked. At a later delay with still no response, the balance is checked, refunded if there is anything in it, and the account closed. Three phases, each with its own queue and its own exit, and a file moves between them whether or not anyone is paying attention.

The held payment version has a shorter clock and a different ending, but the same structure: a window, a reminder, and an escalation that fires on its own.

Two things make this work beyond the deadlines themselves. Cases are dispatched rather than picked, so nobody works the easy files and leaves the hard ones to age. And the queue is read by phase, so your team sees how many files are approaching a block rather than how many are open in total. Inbox and dispatch is where that lives.

Regulator and sponsor-bank requests run the same way

When the counterparty is a supervisor or a sponsor bank, the direction reverses. They ask, you answer. The mechanic does not change.

A request arrives, usually by email. The answer needs data assembled from several systems, a review by people in more than one team, and a package sent back through whatever channel the counterparty uses. Your team is still holding an open obligation with a deadline attached, still waiting on someone, and still needing to show afterwards what was sent and who approved it.

The difference is what the archive has to prove. For a customer RFI, your team needs to know the request went out and the answer came back. For a regulator, the response itself becomes a record that may be read again years later, so the assembled bundle, the approvals and the transmission all belong on the case rather than in a mailbox.

The RFI workflow pattern, step by step

This is the flow as it runs on Forest, from a screening hit through to a released payment.

When nobody answers

Step 5 is the one that can stall, so it carries its own schedule rather than a single deadline. A reminder, then an escalation, then whatever your policy says happens to an account that never replied. Each phase is its own queue with its own exit, so a file that goes quiet moves forward anyway.

What the archive holds

Every one of those steps writes to your database as it happens: who asked, when, what was sent, what came back, who decided and on what basis. A regulator asking about a single payment two years from now gets the chain rather than a reconstruction, which is the same reason the audit trail sits under every other process your team runs.