A cross-border payout RFI (request for information, a compliance hold that asks for a document before a transaction clears) is a request from a payment provider's compliance team for missing or corrected details about a customer, an account or a single payout. The affected object pauses until someone answers. It asks for clarification and does not refuse.
This post covers the four kinds of RFI, what each asks, which document answers which question, and how to reply once instead of three times. If the payout was refused outright rather than paused, that is a different event, covered in why a stablecoin payout gets rejected.
What are the four kinds of RFI on a cross-border payout?
An RFI attaches to one of four objects. The object decides what stops, who is asked, and how you answer. A customer RFI comes out of KYB (know your business, the verification of a company and its owners) or KYC (know your customer, the verification of an individual). The other three come from account provisioning, transaction monitoring and limit reviews.
The four objects an RFI can attach to, what each one asks, and how the reply travels
RFI on a | What triggers it | What it asks for | How you answer |
Customer | A KYC or KYB review finds missing or invalid data | The documents or fields named in the status reason: a sharper ID, a matching proof of address, an ownership chart | Re-submit through the onboarding endpoints, then start a new verification |
Account | Compliance needs more to provision a virtual account | The specific information compliance lists for that account | On the channel compliance used, email or Slack |
Transaction | Monitoring flags an on-ramp or off-ramp and holds it | Who sent and who receives, the purpose, the expected outcome and any context | On the channel compliance used, within 24 hours |
Limit request | The document behind a limit increase does not justify the amount | Additional or corrected documentation | Resubmit through the same limit increase flow |
Only the transaction RFI is a payout RFI in the strict sense, and a limit increase request counts as one only when the limit is a requirement to approve a specific transaction. The other three decide whether a payout can happen at all. In each case the affected object pauses and waits for you to submit what is needed. A customer RFI ends when the customer is approved, and an account RFI that cannot be resolved ends in REJECTED. A held transaction waits for you while the clock runs.
With us, each level has its own signal. Customer RFIs arrive as a customer.rfi webhook with a status reason that lists the documents at issue, and account RFIs as account.rfi. Transaction RFIs come from compliance directly, by email or Slack, and the reply goes to operations@lumx.io.
Why compliance sends an RFI instead of refusing
Because the rules ask a provider to know who it serves and why money moves, and a gap in that file is cheaper to close than to cure by ending the relationship. The FinCEN customer due diligence rule is a useful reference for what these programs look for: covered institutions must understand the nature and purpose of customer relationships, identify the beneficial owners of the companies they onboard, and on a risk basis keep customer information up to date (see the FinCEN CDD final rule). The rule itself covers banks and similar institutions, and money services businesses have their own program rule, 31 CFR 1022.210. An RFI closes the gap without a refusal. The FATF revised Recommendation 16 on payment transparency, published on June 18, 2025 with implementation targeted for the end of 2030, pushes the same way for data that travels with a cross-border payment.
Three things tend to start one:
A file that does not agree with itself, such as an address on the proof that differs from the registered address.
A risk tier that calls for more depth, either from the customer's country, industry or risk score or from a material change in expected activity.
A payment whose purpose or counterparty compliance cannot read from the request alone.
The last is the most avoidable: every on-ramp and off-ramp request carries a purpose code, and misclassifying it can trigger an RFI or a hold, per the docs. Monitoring rules are in stablecoin AML compliance for fintechs, customer-side checks in what KYB is.
Lumx asks for source of funds or source of wealth documentation when a customer lands in an enhanced due diligence tier, when volumes or funding structures need validation, when activity or ownership changes materially, or when a regulation requires it. The RFI lists the documents.
What compliance asks, and the evidence that answers it
Most RFIs ask a small number of questions in different clothes. The table maps each ask to the document type the API accepts and to the check that decides whether the reply holds up. Checks in plain text are rules from the Lumx docs, and checks in italics are our advice, not a published rule.
Common RFI asks, the document that answers each, and what to verify before you send it (docs rule, or our advice in italics)
What compliance asks | Document that answers it | Check before sending (docs rule or our advice) |
Who is the person behind this ID |
| Valid, fully visible, both sides where a side is required, a live photo |
Where does the business operate |
| In the legal name as registered, issued in the last 90 days, a physical address and no PO box. For a proof of address, a screenshot is not accepted unless compliance pre-approves it |
Who owns the company |
| Every owner above 25% appears. The percentages match the application |
Who runs it |
| Current officers, matching the representative named at onboarding |
Who may act for it |
| Names the person who is actually submitting |
Is the activity regulated |
| A licence that covers the activity declared at onboarding |
Where did the money come from | A bank statement, revenue invoices or contracts, a loan agreement, or asset sale records | In the name of the funding entity, legible, no material redactions, PDF, JPG or PNG |
Where did the crypto come from | Wallet ownership proof, transaction history or exchange statements | The wallet that funded the payment is the one you prove |
Why was this payment made |
| The invoice names the same customer that sent the funds |
Why this limit |
| The statement supports the monthly volume you requested |
Three habits repeat across the rows: names match across documents, dates are recent, and every figure traces to a page someone can open.
The 24-hour clock on a held payout
A held payout is the RFI with a deadline. When monitoring flags an on-ramp or off-ramp and compliance cannot clear it internally, they send the transaction details and usually ask for four things: the relationship between sender and receiver, the purpose of the payment, the expected outcome, and any other context that clarifies it. If you do not respond within 24 hours, the transaction may be refunded to the sender. The 24-hour window applies to all transactions.
Answer in the order they asked, and write each line for a reader who knows nothing about your business. A line such as "supplier invoice 2026-091 for the October shipment, paid by us to the supplier named on the attached contract, expected to settle in the supplier's local account" gives compliance the relationship, the purpose and the outcome, with the paper attached. "Business payment" gives them a reason to ask again, and vague replies tend to trigger another question while the 24 hours keep running.
After a missed window the payment goes back to the sender and has to be started again. For payouts that are tight against a cut-off, the timing rules are in the limits and cut-offs by rail.
With Lumx, compliance reviews the flagged on-ramp or off-ramp by hand. If it is not a false positive, compliance writes to you on your usual email or Slack channel with the transaction details, and decides whether to release the transaction once you reply. An API for transaction RFIs is expected between the end of 2026 and the first quarter of 2027.
How to answer an RFI the first time
The sequence is short. What fails is the handover between whoever sees the RFI and whoever holds the proof.
Read the whole request before you collect anything. It lists what is at issue, down to the document, and a reply that fixes two of three items leaves it open.
Gather the evidence from the table above and run the check column against it.
Submit everything together. Partial replies restart the review.
Keep the reply on the channel the request came in, with the transaction or customer identifier quoted in the first line.
After you reply, compliance reviews the answer and decides: a customer is approved or sent a new RFI, an account moves back to provisioning, and a held transaction is released or not. The docs publish no review time for transaction RFIs, so do not plan around a figure. The docs do publish a review target for limit increases, one day, as a target only.
For a customer RFI, the reply is an API flow. Fix the field with PATCH /customers/{id}/additional-information, replace a document with POST /customers/{id}/documents, re-upload the files of any flagged associated party (a UBO, shareholder or representative), then start a new verification with POST /customers/{id}/verifications. The customer returns to UNDER_VERIFICATION, and you get customer.approved or another customer.rfi. Subscribe to customer.rfi and surface the status reason in your own product, so the person with the documents sees the request. The customer webhooks cover requests for documents. Open questions about how the business works still go by email or Slack. An API for account RFIs is due this year, and one for transaction RFIs is expected between the end of 2026 and the first quarter of 2027.
Who should answer, and who should not
I would give every RFI reply one named owner, and I would not make that person whoever happens to be on call for the integration. The reply is a compliance document, not a support ticket: it has to say what the payment was for and attach the paper that proves it, and an engineer rarely has either. The first question I would ask a partner is who that person is, because the answer decides whether the first reply is also the last one.
The owner does not have to be senior. They need access to invoices, ownership records and the customer, and the authority to send them.
When chasing the RFI is the wrong move
A payout refused at the API, before a transaction exists, is not an RFI. It returns a code and needs a change in your request. A FINAL_REJECTION is permanent: the customer cannot resubmit and cannot be re-verified, so the work is a conversation with your customer. And a limit that is simply too low calls for a limit increase request, with its own review and supporting documents.
Sometimes the paper does not exist. A fluent reply will not help a customer who cannot show where the money came from, and padding it with documents that do not fit turns a clarification into a final decision. Say so early and ask what compliance would accept instead.
How an RFI plays out on a payout with us
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
KYB, account provisioning and transaction monitoring sit inside the same API, so the RFIs arrive from one compliance team under one naming. The status is RFI on the customer and on each associated party, the webhooks are customer.rfi and account.rfi, and the reply to a customer RFI goes through the same endpoints used at onboarding. The old status name, TEMPORARY_REJECTION, became RFI on May 25, 2026, so integrations matching the old string need the update.
When a payout is held, the request that matters is the one you made: the purpose code, the destination holder and the relationship to the customer are what compliance reads first. Pick the purpose from the economic substance of the payment, and use PERSONAL_ACCOUNT only when customer and destination holder are the same legal entity. Review tiers by country are on the supported countries page, live rails on the coverage page and the payout in global payments. The conversion behind it is in what a stablecoin off-ramp is, and where most customer RFIs start in designing a KYB onboarding flow.
Methodology and sources
Every status, webhook, document type and timing quoted here comes from the Lumx documentation, and the document checks in plain text are the docs' own rules; the checks in italics are our advice, read on November 1, 2026: the Request for Information page, Source of Funds and Wealth, Proof of Address, Document Types, Purpose Codes, Transaction Limits, Identity Verification and the changelog entry of May 25, 2026. The customer due diligence summary is from the FinCEN CDD final rule, read on November 1, 2026. The publication date of the FATF revised Recommendation 16 was confirmed on the Japan Financial Services Agency's FATF page, read on November 2, 2026, because the FATF site blocked automated requests.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Dave Meckler on Unsplash.
What is a cross-border payout RFI?
A cross-border payout RFI is a request for information from a payment provider's compliance team. It asks for missing or corrected details about a customer, an account or one payout, and the affected object waits until the answer is reviewed. With Lumx, an RFI can sit on a customer, an account or a held transaction, and each one reaches you through the webhook or the compliance channel described in the docs.
How long do we have to answer an RFI?
The documented clock is on a held transaction: if you do not respond within 24 hours, it may be refunded to the sender. For customer and account RFIs the docs give no deadline, but the object stays paused until you submit what is needed, and an account RFI that cannot be resolved ends in a rejection. With Lumx, a held on-ramp or off-ramp gets an RFI from compliance on your usual email or Slack channel, so name who watches that channel.
Can a payout or a customer keep working while an RFI is open?
A held transaction stays held until compliance reviews your answer and decides whether to release it. A customer or account in RFI is paused and waits for you to submit what is needed. With Lumx, the customer returns to under verification once you resubmit, and you receive either a customer approved event or a new customer RFI event.
Can we answer an RFI through the API?
On Lumx, for a customer RFI, yes: update the additional information, upload the corrected documents and start a new verification through the same endpoints used at onboarding. For account and transaction RFIs an API is expected (account this year, transaction between the end of 2026 and the first quarter of 2027), and until then the reply goes by email or Slack to the compliance contact who wrote.
How do we avoid an RFI in the first place?
Send complete and consistent data: names that match across every document, a proof of address from the last 90 days, ownership percentages that agree with the registry, and the right purpose code on every payout. On Lumx, the purpose code is a field on each on-ramp and off-ramp request, and the docs state that choosing the wrong one can trigger an RFI or a hold.
