If you’ve ever had a seemingly straightforward cross-border payment stall at the last mile, chances are an RFI, or Request for Information, was involved.
Now, before we dive further into the topic it’s very important to reiterate: RFIs exist for a very good reason. They are a tool in maintaining compliance and ensuring that clients, customers, and anyone moving money is following regulatory standards and best practices. We’ll get further into that below.
And that said: RFIs are one of the most persistent, universal frustrations in global payments. They can delay transactions, confuse users, or force operations teams to scramble for documentation.
We sat down with Jack Murphy, Head of Product at Rail, to get to the bottom of why RFIs are so tricky — and how Rail’s new Up Front RFIs feature is setting a better standard for payment clarity, speed, and control.
Jack:
An RFI stands for “Request for Information”. It is a request to provide more context and/or supporting documentation to a payment. Only when this information is provided and reviewed will the payment be processed.
RFIs may get triggered before the payment is accepted or while the payment is in-flight. They can lead to processing delays if they are not responded to and satisfied quickly.
While RFIs may seem like arbitrary speed bumps that delay payments, the reality is they are not. RFIs are about managing risk and regulatory compliance, especially in a world where transactions cross jurisdictions, involve third parties, or rely on complex chains of custody. RFIs act as a pressure valve — when something looks off or under-documented, the payment pauses while it’s investigated.
The challenge for us at Rail is how we can empower clients to manage RFIs effectively. Thus reducing any potential delays in processing payments.
Jack:
Unfortunately not. Stablecoins are the easiest part of executing global stablecoin payments. Existing challenges such as counterparty risk, AML, fraud are still present and must be mitigated.
RFIs arguably become even more important in a hybrid system where fiat and stablecoins interact. If a business sends USDC to a counterparty that ultimately gets paid out in fiat or vice versa there has to be a clear, documented chain of legitimacy. Banks and regulators want to know that the same compliance standards are upheld, no matter how fast or modern the underlying tech is.
The opportunity here is to do better. Stablecoin infrastructure gives us flexibility, and now it’s up to us as an industry to make sure compliance processes are just as flexible and intelligent. That’s the bar we’re holding ourselves to at Rail.
Jack:
While this is a valid solution, it is like using a sword to perform surgery when you need the precision of a scalpel! Not all payments will trigger an RFI, so it doesn’t make sense to put the burden on clients to provide such detailed context and supporting documentation for EVERY payment. Only the payments that warrant further investigation.
For example, a payment for $10, where counterparties are the same entity (self transaction/treasury management). This payment likely doesn’t need much additional context or supporting documentation.
However, a payment for $10 million, where one counterparty is an individual living in the US and the other is a business based in Panama. This payment is likely going to require additional information and supporting documentation.
Jack:
Traditionally, RFIs were hard to solve because they were completely manual. Banks trigger an RFI, they reach out to the customer directly via email, the RFI is a wall of unstructured text where it’s often not clear what’s being asked.
That is not the approach we’re taking at Rail. Our goal is to simplify and automate the process as much as possible, making it easy for clients to respond to RFIs and ensuring payments are processed as quickly as possible.
Jack:
We’ve launched a new capability called Up Front RFIs.
Here’s how it works: before a withdrawal or payment is accepted and processed, our system evaluates whether the operation requires more information or not. If it is, we pause the flow before it leaves the gate, notify the client, and request the necessary documentation right then and there.
You’ll get a clear webhook notification, API access to the required documents, and a way to upload everything before proceeding. The goal is to reduce back-and-forth, give clients more control, and dramatically cut down on surprise delays.
This might feel like a bit more work up front, but it’s work you already have to do eventually. We’re just bringing it forward to avoid delays when speed matters most.
Jack:
This is just the first step.
Our vision is to build a platform where friction is predicted and solved before it becomes a problem. Where clients know what’s coming, and have the tools to handle it efficiently. We’ll keep refining our triggers, surfacing better guidance, and making compliance feel like less of a blocker and more of a built-in safeguard.
We’re also looking at more ways to help our clients educate their end customers, automate document collection, and improve metadata quality so that RFIs aren’t just resolved faster — they’re avoided entirely.
Long-term, we want to turn RFIs from a reactive scramble into a proactive, intelligent layer of the payments experience.
RFIs aren’t going away — but they can be made smarter, faster, and more predictable.
Rail’s new Up Front RFI feature is just one part of our larger commitment: to build global payment infrastructure that’s fast, clear, compliant, and built for growth.
RFIs can feel like one of payments' biggest pain points. Learn why they matter (and what Rail is doing to make them easier)
.svg)
.svg)
