When it comes to today’s cross-border landscape, legacy banking pipelines are largely fragmented. While existing payment orchestration provides connectivity, it does not solve the core structural problems of multi-entity reconciliation and settlement. Transaction routing systems introduce additional fees and latency, and each intermediary screens the payment on its own schedule, making settlement windows unexpected and unpredictable.
Add on another layer: data, and the problem becomes easier to miss and more complex to solve. In a multi-hop correspondent chain, structured remittance fields, ultimate debtor identifiers, and invoice references are stripped during format translations between intermediary core banking systems. That loss breaks straight-through processing for ERP systems and forces manual exception handling at the receiving end.
Replacing these intermediaries requires fully owned, vertically integrated rails. True scale in global payments comes from owning the whole stack rather than layering software over infrastructure someone else controls.
This is where PingPong Payments becomes an interesting case study. It holds 82 licences and authorisations worldwide, clears through direct connections to the payment schemes rather than third-party aggregation layers, and, in the markets where it holds its own regulatory permissions, issues local account details in its own name rather than a partner bank’s.
PingPong was originally built around the lifecycle of money rather than around separate payment products. Its infrastructure now processes more than $300 billion in annualised volume for over 750,000 active business clients across more than 200 markets. This puts it alongside some of the largest players in this space, including Airwallex and Checkout.com.
It is worth being clear about what that model costs, and the strength of the moat it creates. Licences take years to obtain and continuous investment to maintain; capital must be held against them, and direct scheme membership carries operational obligations an orchestration layer never has to think about. The argument for vertical integration is not that it is cheaper to build. It is that it is cheaper to run at volume, and that control over the payment becomes a product capability rather than a dependency.
The first hard problem starts before the payment
In older payment setups, identity and risk checks often sit before the transaction flow. A business submits its information, compliance systems run their checks, and anything uncertain ends up in a review queue. I have seen how quickly this becomes a product problem. A payment may be perfectly normal, but one weak signal can hold it up while someone investigates.
A full-stack payment engine handles this differently. Risk checks become part of the transaction flow. As a payment comes in, the system can pull company data from official registries and work through ownership structures to identify the people behind the business. Sanctions screening can happen at the same time. Much of this can run automatically within seconds.
That information can then influence what the payment engine does next. A company with a long history of verified activity may receive higher transaction limits and move through with little friction. A new business sending an unusual payment from a new device may face another check. The system can look at the connection source and compare the transaction with previous behaviour before deciding what action to take.
This is where I think the design of the payment stack matters. Compliance should be able to react to the risk of a specific payment instead of treating every transaction the same way. If something looks unusual, the engine can request a document or apply another check to that case in that moment, versus waiting until the end to decide. Meanwhile, verified payments can continue processing without being pushed into the same review queue.
What that buys is easy to state and hard to build. Fewer legitimate payments are stopped, so approval rates rise. Verification runs against live registry data rather than a document queue, so the gap between onboarding a client and clearing their first payment narrows. And the cost of compliance stops climbing in a straight line with volume, because the expensive checks are the ones the risk actually warrants. Screening becomes a variable cost, priced to the payment in front of it, rather than a fixed toll charged on everything that passes.
Virtual accounts and native clearing
Getting paid across borders is often harder than sending the payment.
A company may invoice a customer in another country and give them bank details connected to a pooled collection account. The customer sends an international wire. Two problems arrive with it. Correspondent banks may deduct fees along the way, so the sum that lands is smaller than the invoice and someone has to chase or write off the difference. Separately, remittance data is stripped in transit, so the receiving company still needs to work out which customer and invoice the payment belongs to. At scale the two compound. A short payment that cannot be matched to an invoice is a reconciliation problem and a collections problem in the same transaction, and finance teams end up solving both by hand.
This is why local collection infrastructure matters.
A full-stack provider like PingPong can issue virtual IBANs and local bank details linked to an individual business. A company in the US or Asia, for example, can collect money through local accounts in the UK or Europe without setting up a legal entity in every market. The payer gets familiar domestic payment instructions and can often pay through the local banking system instead of sending an international wire.
The difference sounds small. Operationally, it is significant.
When each virtual account is mapped to a customer or invoice, an incoming payment already carries useful information about where it belongs. The ledger can match the payment against an open invoice and pass that information into the company’s ERP. Treasury teams spend less time investigating incoming transfers and asking customers to provide payment references.
The same collection layer can support cards, bank transfers and more than 160 local alternative payment methods through one integration. Depending on the market, that can mean rails such as ACH in the US, SEPA in Europe, or Faster Payments and CHAPS in the UK. The payment method can change while the merchant keeps a common ledger and reconciliation layer.
Allocation is the part most providers leave to the platform. A multi-billion-dollar global marketplace launching across six European markets found the difficult problem was not moving money but dividing it. Every marketplace transaction contained at least three claims against the same incoming payment: a logistics fee, a platform fee, and a seller payout. Splitting and sweeping those automatically at the point of collection, rather than reconciling them afterwards, removes a standing workload from finance and operations teams. A single EMI licence in Luxembourg, for example, passported across 30 EEA states, covers every launch market without a separate banking relationship in each one.
There is a harder infrastructure question underneath all of this: who provides those local account details?
Many payment companies rely on banks or other licensed providers to supply accounts in markets where they do not have their own regulatory access. That can work well, but it creates another dependency in the payment chain. If a banking partner changes its risk policy or decides to stop serving a particular customer segment, the payment company has limited control over the outcome.
Building more of that infrastructure directly is expensive. It means obtaining the right licences, connecting to banks and payment systems, protecting customer funds and meeting capital requirements. The company must also maintain those controls as regulations change. But this investment gives the payment provider more control over how money is collected, held, and reconciled across markets.
The difference becomes more important once the money arrives
The ledger is where a cross-border payment platform starts to look like a treasury system.
At its inception, PingPong was built to help Asian e-commerce sellers collect marketplace revenue, convert currencies, and pay suppliers. As the company moved into B2B trade and then enterprise payments, those flows became more complex. Today, its broader stack includes multi-currency collection accounts, wallets and FX alongside payouts, issuing, and acquiring, all available as managed accounts through its API-based platform.
Think about a global marketplace. It might collect euros from European customers this morning, receive dollars later in the day, and have suppliers that need to be paid in several other currencies. Converting everything back into one base currency after every transaction creates unnecessary FX costs. A multi-currency ledger allows the business to hold those balances and use them again when the next payment needs to go out.
That changes the economics.
If a business already holds euros, a euro payment can be funded from that balance. The same principle can apply when a commercial card is connected to the wallet. Instead of converting the company’s base currency every time the card is used abroad, the platform can draw from the balance in the currency needed for that transaction.
Best Buy Canada is a useful example of what this unlocks. While running a third-party marketplace since 2016, its seller base was effectively domestic. In March 2025, it appointed PingPong as its first cross-border payment service provider of record, embedding payouts to international sellers through a single API integration. Best Buy Canada made the switch to lift gross merchandise volume, cut operational overheads, and improve the experience on both sides of the marketplace, and its marketplace leadership described the onboarding as fast. Wish and Wayfair run on this same infrastructure.
It’s worth noting that if a marketplace cannot pay a seller in that seller’s own currency, on rails that seller already uses, it cannot recruit that seller at all. The constraint being removed there is worth naming precisely, because it is not payment cost. It is seller supply. A marketplace that cannot pay a seller in that seller’s own currency, on rails that seller already uses, cannot recruit that seller at all. Cross-border payout capability is therefore a seller acquisition decision before it is a treasury one.
Liquidity management and embedded FX
But holding currencies creates another problem: liquidity.
PingPong has built a network that allows it to manage liquidity across markets. Once funds enter its network, the company can pay them out elsewhere, which has allowed it to support real-time, 24/7 payments for years. The infrastructure behind that includes 82 licences and around 200 banking partners, including relationships with Tier 1 banks.
FX gets more interesting once you move beyond a simple currency conversion.
Travel is a good example. An online travel company may find that the same airline ticket is priced differently across markets. Buying in another market can create an opportunity, but the company may have to settle with that airline at a later date. The ticket price may seem more attractive today, but the exchange rate may move against the company in that window before settlement.
So, the payment workflow needs to deal with that FX exposure at the moment the transaction is created.
PingPong’s approach embeds FX pricing into the company’s workflow and locks the relevant rate for the settlement period. This allows the purchase to be made with the FX cost known upfront, rather than leaving its treasury team to hedge the exposure separately.
Sabre faces exactly this on international bookings through its global distribution system, where the agency’s price is fixed at the point of booking, and the obligation to the supplier falls due days or weeks later. Pricing for the locked rate is aggregated live from more than ten liquidity partners and held through settlement.
I think this example explains why enterprise FX is easy to underestimate. A competitive spot rate matters, but enterprises often need much more than a cheap conversion. They need the FX product to understand the payment that sits behind it.
This is where the ledger, liquidity network, and FX engine start working as one system. The platform knows which currencies the business holds, which payments are coming in, and what needs to leave. In using smart-pricing engines, it’s much easier to decide when conversion is required and how best the FX exposure should be handled.
For an enterprise treasury team, this can remove a surprising amount of work from the payment process.
The final challenge is choosing how to deliver it
PingPong connects directly to schemes such as SEPA, Faster Payments, Bacs and CHAPS. It also uses SWIFT and local payment rails across different markets. That gives its routing engine several ways to move the same payment.
The practical effect is simpler than it sounds. A payment entering the network at one point can be paid out at another, without an international wire in between. Global liquidity management is what makes that possible.
I think the routing part is especially important. Cross-border payments are often discussed as if there is one best route. There isn’t. An enterprise may want the cheapest route for one payment and faster settlement for another. PingPong is using AI to make these routing decisions based on what matters to each customer, including the trade-off between speed and cost.
Risk controls must follow the payment through those routes. The useful question is not how much transaction monitoring a platform runs, but how few false positives it produces. Every held payment is a customer service cost, and at enterprise volume those costs compound faster than the fraud losses they prevent. A legitimate payment should keep moving. Transactions that need more information can be held for further checks.
Payout mesh and BPSP architecture
To execute mass international disbursements, vertically integrated engines run payout networks reaching more than 200 markets, paying out in 25 or more currencies over domestic clearing channels rather than correspondent chains.
That same infrastructure can also extend into enterprise supplier payments, where a different constraint emerges: many suppliers do not accept commercial cards. Interchange costs, merchant onboarding requirements and long-settled billing habits keep a large share of corporate spend outside the card rails altogether.
The Business Payment Solution Provider (BPSP) framework operated by the card networks exists to close that gap. Under it, an enterprise settles an invoice on its existing commercial card and the supplier receives an ordinary bank transfer, without ever onboarding as a card-accepting merchant. PingPong built its own version of this, Card to Account, with Visa, launching in May 2026 as one of three foundational providers selected for the programme. It is live in the UK, the EU and Hong Kong, with the US and Singapore following across 2026.
In practice the flow has three steps:
The buyer settles supplier invoices on an existing commercial card programme, deferring cash outflow by up to 45 days without taking on new debt.
The payment engine acquires the commercial card charge and routes an equivalent domestic bank transfer directly to the supplier’s domestic bank account via local clearing rails, reaching suppliers in more than 170 countries and 25 currencies, with funds landing between the same day and two days later.
The supplier receives a standard domestic bank transfer without maintaining merchant card acquiring facilities or absorbing interchange discount rates.
Consolidating card acquiring, foreign exchange conversion and domestic clearing inside one platform removes the external gateway mark-ups that legacy BPSP models carry. It also shortens the chain itself. The fewer external systems that sit between the card being charged and the money reaching the supplier, the fewer places a payment can stall and the less reconciliation work lands on the treasury team at the end of it.
The infrastructure advantage
Software is becoming the easier part of cross-border payments.
A well-funded team can build APIs and connect payment providers relatively quickly. Nothing in the software layer is genuinely defensible. Given enough time and money, any payment interface can be replicated, and product development is getting even faster with AI.
The harder part takes years.
PingPong participates directly in schemes such as SEPA, Faster Payments, Bacs and CHAPS. That infrastructure gives it more control over how payments move and how liquidity is managed across markets.
The banking relationships are particularly difficult to copy. They are built up over years and granted on trust, demonstrated capability, and confidence in the strength of a counterparty’s compliance and risk controls. A new entrant with unlimited capital can buy engineers. It cannot buy a track record.
This is where I think the gap between a payment interface and a full-stack provider becomes clear. The API can be built quickly. Licences cannot. Neither can years of compliance history or the banking relationships needed to support global collections and payouts.
For an enterprise choosing cross-border infrastructure, those layers matter because they determine what the provider can actually control when money starts moving.
Disclaimer:
Fintech Wrap Up aggregates publicly available information for informational purposes only. Portions of the content may be reproduced verbatim from the original source, and full credit is provided with a “Source: [Name]” attribution. All copyrights and trademarks remain the property of their respective owners. Fintech Wrap Up does not guarantee the accuracy, completeness, or reliability of the aggregated content; these are the responsibility of the original source providers. Links to the original sources may not always be included. We use AI tools to brainstorm, draft, edit, and summarize, but the ideas, analysis, and connections Sam draws are his. Every piece is verified and written in Sam’s voice. For questions or concerns, please contact us at sam.boboev@fintechwrapup.com.