FXC Intelligence Cross-Border Payments: Using the Research
FXC Intelligence helps explain the cross-border payments market. For finance teams, the practical value comes from matching its research to the payments they actually make—and knowing where market intelligence stops.
FXC Intelligence is a specialist cross-border payments data and research firm, not a payout execution platform. Its research helps banks, payment companies, investors, and finance teams understand market size, pricing, competitive positioning, and payment trends. For businesses paying vendors, contractors, or sellers internationally, its most useful role is to provide external context for internal payment decisions.
The distinction matters: market intelligence can tell you what to investigate; it cannot establish what your business will pay or when a particular recipient will receive funds. Using FXC Intelligence cross-border payments research well means connecting the right dataset to a specific question, then validating the answer against your own quotes, contracts, and transaction records.
What FXC Intelligence provides
FXC Intelligence describes its offering as cross-border payments data and intelligence, alongside payment card industry data. Its coverage spans business and consumer payments rather than a single payout use case.
That breadth creates several useful research entry points:
- Market sizing: Understand payment flows and the relative scale of countries, corridors, and customer segments.
- Pricing intelligence: Investigate FX margins and cross-border fees across relevant markets and use cases.
- Provider research: Identify companies and understand their role in the competitive landscape.
- Industry analysis: Follow developments such as regional expansion, infrastructure changes, and emerging settlement models.
Public reports and commercial datasets are not interchangeable. Before building a business case around either, confirm the available fields, coverage, observation dates, access terms, and permitted uses. A public summary does not establish that a particular corridor-level extract is available to you.
Match the research to the decision
The following framework is an editorial guide to using research, not a rating of FXC Intelligence products.
| Research input | Useful finance question | Evidence still needed | Interpretation limit |
|---|---|---|---|
| Market flow estimates | Where should we investigate demand? | Own recipient and invoice mix | Market size is not payout demand |
| Pricing observations | Which costs deserve review? | Matched quotes and contracts | Observed price is not your price |
| Revenue and take rates | Where may pricing pressure exist? | Segment and corridor definitions | Provider yield is not buyer cost |
| Provider landscape | Who belongs on a research shortlist? | Eligibility and service validation | Inclusion is not certification |
| Rail and technology analysis | Which assumptions should we test? | End-to-end payout evidence | Rail speed is not recipient availability |
Build a comparable benchmark before judging price
FXC Intelligence's market sizing data offering describes country- and corridor-level flows across consumer and business segments, together with revenue and take-rate data. This granularity is important because a global average can obscure the economics of the payments your business actually makes.
For a finance team, however, geography is only the starting point. Two payments to the same country can have different costs because they use different funding currencies, payout methods, customer agreements, or payment amounts.
Create a benchmark specification
Document the following before comparing an external observation with an internal transaction:
- Direction and currencies: Sending country, receiving country, funding currency, and recipient currency.
- Customer and recipient type: Consumer or business sender; individual or business beneficiary.
- Amount and pricing basis: Payment size, contractual volume tier, and whether the quote fixes sender debit or recipient credit.
- Funding and delivery method: Bank funding, wallet balance, or another supported method; bank account or other payout endpoint.
- Observation timing: Quote timestamp, FX reference timestamp, and quote validity.
- Included charges: Transfer fees, FX markup, possible deductions, and separately billed platform charges.
If those dimensions cannot be matched, label the comparison directional, not evidence of overcharging or achievable savings. In particular, consumer remittance pricing should not be presented as a directly available corporate payout rate.
Compare like-for-like economic outcomes
For an invoice that must arrive in full, compare total sender cost for the same net recipient amount. For a fixed payout budget, compare the net amount received for the same total sender debit. Mixing those approaches can make a deducted fee disappear from the analysis.
Keep operational costs separate from quoted payment costs. Exception handling, reconciliation effort, and the cost of maintaining prefunded balances matter, but they are not necessarily included in an external pricing observation. The cross-border payment fee review framework provides a practical companion for examining those cost components.
Do not translate market take rates into your savings target
FXC Intelligence's March 2026 release reported that retail cross-border payment take rates declined across segments between 2022 and 2025, while payment flows grew faster than the revenue pool. Its analysis of market growth and tightening take rates emphasizes the importance of corridor and segment mix.
That is useful negotiation context, but it does not prove that your provider's margin fell—or that your contract should fall by the same amount. A market take rate reflects revenue relative to payment flows within the research scope. Your effective cost reflects your own transaction mix and commercial terms.
To distinguish repricing from a change in payment mix, compare costs within matched groups of payments before calculating a blended result. If more of your volume shifts toward inexpensive corridors, the average cost can improve even when no provider changes its rates.
Similarly, if a proposal relies on holding funds locally to improve conversion timing, evaluate that treasury change separately. Multi-currency accounts can support collecting and holding funds, but retained balances introduce liquidity allocation decisions that a transfer-price benchmark alone cannot resolve.
Use the Cross-Border Payments 100 as a landscape, not a recommendation
The FXC Intelligence Cross-Border Payments 100 identifies significant companies across the industry. Its selection criteria consider factors such as significance within a market or segment, the importance of cross-border payments to the business, and growth.
Those criteria support market discovery. They do not establish that each company can serve your legal entity, recipient countries, payment purposes, or operational requirements. The list spans different business models; companies on it are not automatically direct substitutes.
Use inclusion to generate questions rather than award procurement points. Ask which services the company actually provides, which customer segments it serves, and whether it controls the recipient-facing payment leg or depends on another institution. Regulatory suitability, contractual responsibilities, and operational performance require separate diligence.
A hypothetical example: turning a benchmark gap into a test
Hypothetical scenario: A business pays contractors in several countries. External pricing research suggests one corridor may be expensive relative to comparable observations. Finance wants to use the apparent gap as a savings forecast.
Instead of immediately changing providers, the team separates payments by amount, recipient currency, and payout method. It discovers that some internal transactions include a conversion before the provider receives funds, while the external comparison starts with funds already available in the sending currency.
The appropriate next step is to obtain comparable end-to-end quotes—not to subtract the published benchmark from historical spend. Finance then checks the net recipient amount, funding requirements, quote validity, and treatment of failed payments.
The research has still delivered value: it identified a question worth investigating. But the resulting business case should use validated economics and explicitly exclude untested payment groups.
Checklist: make research usable in a finance decision
- Define the question. Separate market expansion, provider discovery, price negotiation, and treasury design.
- Record the source. Capture publication date, data period, segment definitions, and whether figures are estimates or observations.
- Check coverage. Confirm direction, currencies, payment amount, customer type, and delivery method.
- Label comparability. Mark each comparison as matched, directional, or unsuitable.
- Request missing evidence. Obtain methodology details, executable quotes, or contractual clarification before asserting savings.
- Validate the full outcome. Check sender debit, recipient credit, funding needs, and actual payment completion.
- Assign a refresh trigger. Revisit the analysis when pricing, payment mix, funding arrangements, or source methodology changes.
Turn market intelligence into controlled execution
FXC Intelligence research is most useful as an external reference for better questions—not as a substitute for transaction evidence. Keep market estimates, observed pricing, provider eligibility, and your own measured outcomes distinct.
Start with a material corridor, write the benchmark specification, and validate the apparent opportunity. Then assess how Payouts.com payout automation fits the execution workflow. The goal is not simply a more persuasive market slide; it is a payment decision finance can explain, implement, and reconcile.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
33 commentsRelated resources
How to Reduce Cross Border Payment Fees: A Finance Playbook
Lower transfer fees do not always mean cheaper payouts. Learn how to negotiate, operationalize, and verify savings across your international payment program.
ClickFunnels Affiliate Payout: Release Rules and Global Payment Checks
ClickFunnels commissions become payable only after eligibility, threshold, and onboarding requirements are met. Here is how to separate earned commissions from money ready to reach your bank.
Does Revolut Support SEPA Instant? Limits and Payout Checks
Revolut supports SEPA Instant, but support does not guarantee that every euro payment will arrive instantly. Here is how finance teams should verify availability, interpret limits, and handle uncertain transfers.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The warning that 'rail speed is not recipient availability' deserves to be in bold. We spent three months optimizing for same-day settlement rails in Latin America only to discover that half our recipients were still getting credited next business day because of local bank posting schedules and weekend gaps.
We hit this exact issue in Brazil. The instant payment rails were technically available but recipient banks had different internal cut-off times for same-day posting. Ended up building a table mapping bank codes to actual crediting windows, which wasn't in any provider documentation.
We had a similar problem in Southeast Asia where the real-time rails were live but posting cutoffs at recipient banks meant anything after 3pm local was effectively next-day anyway. The infrastructure readiness reports don't capture those operational constraints.
The section on matching observation timing is something we completely missed in our last audit. We were comparing quotes from different months during a period of significant FX volatility and treating the variance as provider pricing差 rather than timing mismatch. Cost us weeks of back-and-forth with our providers before we realized the issue.
We hit this exact problem. Even worse, we were comparing live quotes against historical benchmark data without checking the reference rate timestamp. The FX delta alone accounted for most of what we thought was a pricing problem. Now we snapshot the mid-market rate at quote time for every comparison.
We built a timestamp field into our audit template after a similar issue. Now we log quote timestamp, FX reference timestamp, and validity window for every comparison. Still doesn't fix the fundamental problem if you're pulling benchmark data from different periods, but at least flags the mismatch before you waste time on it.
The framework table matching research input to evidence needed is probably the most practical thing I've seen on this topic. We've wasted hours in meetings where someone pulls a market report number and treats it like a SLA we should hold our provider to, when half the variables don't even match our setup.
We now require anyone citing external benchmarks to fill out that specification table first. If they can't match at least five of those dimensions, it goes in an appendix as context only, not into the business case. Saves so much time.
Same experience here. The worst was when procurement brought in a consumer remittance benchmark for our B2B vendor payouts. The article's point about customer segment matching is not theoretical—those rate cards are completely different products.
The framework is solid but I wish there was more on how to handle situations where your provider simply won't disclose the components FXC Intelligence tracks. We've asked our bank for corridor-level FX margin breakdowns three times and keep getting rolled-up blended rates that make any serious benchmarking impossible.
We had the same problem until we switched tactics—stopped asking for margin breakdowns and started requesting matched quotes for specific test transactions with full transparency into the conversion rate, reference rate source, and timestamp. Then we compared those against mid-market at the same second. Most banks will provide that level of detail when it's framed as transaction validation rather than a data request.
We had the same problem until we switched tactics—stopped asking for margin breakdowns and started running parallel live quotes with two other providers for identical transactions. Sent the comparison back with our renewal terms and suddenly the transparency improved. Not ideal, but sometimes competitive pressure opens doors that direct questions don't.
The point about not conflating market intelligence with actual execution is something we should have printed and taped to the wall during our last provider review. We spent weeks building a model around FXC corridor data only to realize none of it answered whether our specific supplier in Vietnam could actually receive funds same-day, which was the entire reason we were switching providers in the first place.
We had the same problem. The corridor data showed Vietnam had competitive pricing, but turned out our supplier only accepted payments through a specific local bank that added two intermediary fees that weren't in any of the market averages. Had to go back and get actual quotes with the full routing specified.
Same issue. The corridor-level data gave us directionality but we still had to run live quotes for every major supplier segment because their banking setup and payment amounts didn't match the research assumptions. Ended up being useful for prioritizing which corridors to investigate first, nothing more.
The point about separating operational costs from quoted payment costs is critical and often overlooked. We spent months optimizing FX margins only to realize our reconciliation team was burning 15 hours a week on exception handling with the cheaper provider. Total cost of ownership is not the same as transaction cost.
This is where the article's operational cost caveat really lands. We track exception handling time now as part of our quarterly provider review, but it took a failed migration to learn that lesson. Did you end up building that 15 hours per week into your total cost comparison retroactively, or just factor it forward into the next RFP?
This is exactly why we started tracking exception rate as part of our provider scorecard. A 0.2% cheaper spread doesn't matter if 4% of payments require manual intervention versus 0.5% with the incumbent. The reconciliation burden has real headcount implications.
The distinction between what FXC Intelligence provides and what you actually need to execute payments is razor-sharp here. We spent three months modeling corridor economics using their data before realizing we hadn't validated whether half our recipients could even receive same-day settlement on the rails we were analyzing.
This matches our experience exactly. We built an entire corridor optimization model from their market data, then discovered during pilot that our contractors in two markets only had access to wallets, not bank accounts, which completely changed the cost structure and timing assumptions.
We had this exact blind spot. The research told us what corridors had faster settlement infrastructure, but nothing about our actual recipient bank relationships or whether they supported real-time rails. Ended up needing to map every beneficiary account to actual delivery capability before the model meant anything.
The warning about mixing sender-cost and recipient-credit comparisons is spot on. We caught ourselves doing exactly that during RFP season—one provider quoted all-in sender cost, another quoted cost to deliver a fixed net amount, and we almost picked the wrong one because the spreadsheet didn't distinguish which number meant what.
We built a standardization layer in our RFP template specifically for this reason. Every provider has to quote both directions—what we pay to send X, and what we pay to deliver Y net—using the same scenario parameters. It's tedious but it completely eliminates the apples-to-oranges problem during evaluation.
We added a required field in our comparison template that forces the analyst to select either 'fixed send amount' or 'fixed receive amount' before any provider data gets entered. Sounds trivial but it completely eliminated that class of error during our last evaluation cycle.
Appreciate the bluntness about market take rates not being your negotiation target. Too many executives see a headline about industry margins compressing and assume our contract should automatically mirror that trend. The reminder that mix shift explains half the story is exactly what I needed to send to our treasury VP who keeps forwarding fintech newsletters without context.
Exactly. We had a board member quote an FXC report showing corridor pricing dropping 30bps, then ask why we hadn't renegotiated. Took three meetings to explain that our volume mix had shifted toward Asia and that the report included consumer flows we don't use.
We had the same conversation with our CFO after a pricing review. Turned out the mix shift toward lower-cost APAC corridors accounted for most of our year-over-year savings, not the actual rate card changes. The matched-cohort comparison approach saved us from claiming credit we didn't deserve.
The benchmark specification checklist is genuinely useful. We've been comparing our EUR→SGD payments against corridor averages without accounting for amount tiers or funding method differences, which now looks naive. Question: how granular do FXC's commercial datasets actually get on the customer type dimension—do they distinguish between SMB and enterprise pricing bands, or is it just 'business'?
The commercial datasets typically segment by sender/recipient entity type (consumer, SME, enterprise) and sometimes by payment purpose code, but the real limitation is volume tier visibility—most providers don't report their step functions to FXC, so you're still doing blind extrapolation from observed midpoints.
The commercial datasets typically segment by sender/recipient entity type (consumer, SME, enterprise) and sometimes by transaction size bands, but corridor coverage varies a lot. For EUR→SGD specifically, you'll want to confirm whether their SME pricing observations include your volume tier—we found good coverage on major corridors but had to treat some Asian routes as directional only.
we learned this the hard way when switching providers last year—compared headline rates, ignored reconciliation costs, ended up spending 40 hours/month chasing payment confirmations that our old setup handled automatically. operational overhead belongs in the TCO model but it never shows up in the pitch deck.
Same issue with recipient confirmations. We built a scorecard that tracked cost per transaction including internal hours. The provider with the worst headline rate actually won because their API pushed delivery receipts automatically instead of us polling three different dashboards.
Same issue with recipient confirmations. We built a scorecard that tracked cost per transaction AND cost per exception by provider. Turned out the cheapest headline rate had 3x the failure rate on certain corridors, which meant our AP team was manually following up constantly. Now we weight reliability at 40% in any RFP.