Beyond the Bank Account

Beyond the Bank Account: What Makes Banking Infrastructure Work for PSPs

The question behind the question

Ask a payments executive which banking relationship they covet, and JP Morgan comes up more often than almost any other name. The more useful question is what they are actually trying to buy, because the account number is the least valuable part of it.

A payment service provider sits between parties that do not fully trust each other. It moves money on behalf of merchants, platforms, and individuals across borders, currencies, and legal systems, and along the way it holds funds that legally belong to someone else. That position turns the PSP's banking relationships into a matter of survival rather than convenience. A PSP with the wrong bank partner, or the right bank with the wrong approvals, can have its entire business model stopped by a single compliance decision.

The problem is structural, and it compounds. Every country a PSP enters brings at least one new account, one clearing path, one set of compliance expectations, and one reconciliation feed. A PSP operating in a dozen markets can easily end up managing dozens of bank relationships, each with its own portal, file format, cut-off time, and risk officer. The cost of this fragmentation is real but rarely visible on a pricing page. It shows up as slower settlement, more reconciliation work, larger idle balances, and teams that spend their time on banking operations instead of product.

Holding other people's money is the part that makes this different from ordinary corporate banking. A manufacturer opening an account holds its own cash. A PSP opening an account holds, even if briefly, the cash of merchants it may never have met. That is a different risk, and banks price and approve it differently. Most of what follows is about that gap: the distance between an account that can receive money and a bank that has genuinely accepted responsibility for the business behind the money.

What PSPs are really buying

The first thing a PSP buys from a large global bank is reach and clearing. Under one relationship, a PSP can cover more currencies, more regions, and more local clearing paths than it could assemble from a patchwork of smaller ones. This matters in two ways. It cuts the operational cost of fragmentation — fewer portals, fewer formats, fewer relationship managers. And it improves reliability: when a payout must reach a supplier in a market where the PSP has only a thin indirect route, the money can sit in transit longer, fail more often, and cost more. A direct clearing path through a bank that already sits on the local scheme removes several of those failure points.

The trade-off is concentration. Putting more of the business into one bank concentrates risk too. If that bank exits a segment, restricts a corridor, or re-prices a product line, the PSP feels it across the whole book. Sophisticated PSPs buy reach from a core bank and keep hedges: a second bank for redundancy, local partners where the core bank is weak, and clear contractual terms on notice periods and exit.

The second thing is FX and liquidity. At PSP scale, FX is a cost of goods, not a feature. The difference between a bank that can quote, hedge, and settle across many currency pairs and one that offers only spot conversion is the difference between a predictable margin and a monthly surprise. A global bank typically offers longer trading windows, forwards and hedging, cross-currency payments, cash pooling, and global position management. These tools let a PSP fund the right accounts at the right time and reduce the working capital trapped in transit.

The value lands in two places. On the margin side, better FX pricing and hedging protect the spread between what a merchant pays and what the PSP actually converts at. On the balance-sheet side, pooling and position management shrink the idle balances a PSP must hold in each currency. Both effects compound with volume. A small PSP can run on a basic FX product; a large one cannot, because the floating cost scales with volume and eats the margin the business was built on.

The third thing is reporting and data standards, the least glamorous part of the relationship and often the most expensive to get wrong. Each bank sends statements, transaction files, and messaging in its own format. Each integration must be built, monitored, and fixed when a format changes. Across many banks, reconciliation stops being a daily task and becomes an engineering program. A bank with relatively unified reporting and messaging reduces that drag, though the reality is uneven: virtual account and wallet products can come with separate portals, limited APIs, or data that does not map cleanly into the PSP's own ledger. A PSP should test the data before it tests the pricing, because what a bank can clear matters less if the PSP cannot reconcile what it cleared.

The fourth thing is fund safety and credit. A banking relationship that matches the PSP's actual business model is a signal to large merchants, counterparties, other banks, investors, and regulators that the PSP's compliance and controls passed a serious review. The signal is valuable, but it only exists when the bank genuinely approved the model. Receiving details issued through an intermediary, without the bank reviewing the underlying business, carry none of that weight. This is where the JP Morgan question gets subtle: the account is easy, and the approval is the product.

The account is the easy part

A bank deciding whether to take a PSP as a client is not really deciding about an account. It is deciding whether it understands and accepts the PSP's business model, whether it will handle third-party funds, whether it accepts the PSP's client onboarding and risk controls, and whether it will open the capabilities the model needs — clearing, FX, sub-accounts, and payments on behalf of others.

Banks are generally willing to sell accounts, clearing, and FX. They are far more reluctant to become the KYC subject for thousands of underlying merchants, or to take on customer-of-customer risk without clarity. That reluctance is the real line a PSP must cross, and it is rarely a credit decision. A well-capitalized PSP can still be declined because the bank does not want to underwrite the PSP's end customers.

The consequence is that two accounts can look identical from the outside while the approvals underneath differ completely. One PSP holds a full-model approval: the bank knows the client base, accepts the funds flows, and has signed off on sub-accounts and payouts. Another holds what looks like the same account but was onboarded through a narrow corridor, with restrictions the PSP discovers only when it tries to onboard a client segment the bank will not touch. The account number does not reveal any of this.

Consider a PSP that opens accounts at two banks. Bank A approves the full model: sub-accounts, client payouts, FX. Bank B issues receiving details through an intermediary without reviewing the PSP's underlying clients. On paper the accounts look alike. The difference appears months later, when Bank B restricts a client segment the PSP had already onboarded. The account was the same; the approval underneath was not. The example is generic, but the pattern is common: the binding constraint on a PSP's growth is usually not the number of accounts it holds, but the set of activities each bank has actually approved.

What the bank is selling

Strip away the brand and a global transaction bank sells infrastructure: accounts, clearing, FX, liquidity, reporting, fund safety, and credit. It does not sell an out-of-the-box PSP operating system. When the business moves into underlying-merchant sub-accounts, customer-of-customer KYC, external payouts, payments-on-behalf-of, and real-time ledgers, the question stops being whether the bank has a product and becomes whether the bank will carry the risk, and whether the PSP has the controls to hold the part the bank will not.

Banks are happy to be the rails. They are cautious about being the responsible party. The distinction defines where the PSP's own work begins. A PSP that assumes the bank will handle compliance for its end customers has misread the relationship: the bank handles its own obligations and will not absorb the PSP's.

The clearest test is a failure. When a merchant goes insolvent with client funds outstanding, when a corridor is restricted mid-flow, or when a currency moves sharply between quoting and settlement, someone absorbs the loss. The bank’s position and the PSP’s position in those moments are defined by the approvals and contracts, not by the account number. A PSP should know, before it signs, which failures it carries and which the bank carries. If that answer is not written down, it will be discovered later, at the worst possible time.

That is why a JP Morgan relationship fits mature PSPs — clear client structure, established compliance, standardized flows — and low-risk, well-bounded new businesses. For a PSP whose model is still shifting, whose underlying clients are opaque, or whose risk framework is not yet built, the harder problem is operating the account after it is opened, not opening it.

How to evaluate your own stack

If you run a PSP, or you buy payment services from one, a few questions reveal more than any logo on a footer.

Which entities sit behind the service? A PSP may market a global platform while the actual account-holding, clearing, and safeguarding are done by partners in different jurisdictions. That structure is normal; what matters is whether the PSP can name the entities and explain how they connect.

Which activities has each bank approved? An account that can receive funds is not the same as an account approved for sub-accounts, client payouts, or payments-on-behalf-of. Ask what the bank signed off on, in writing, and what happens when a client segment falls outside it.

How are client funds held and safeguarded? The answer varies by jurisdiction and product. Client money accounts, safeguarding accounts, e-money, and custodial arrangements are different things with different protections. A provider should be able to explain the mechanism without reaching for slogans.

What are the exit and contingency terms? Banking relationships end, get re-priced, or get restricted. A PSP should know its notice periods, its ability to move flows, and what happens to client funds if a relationship is terminated.

How does the reconciliation data actually flow? The cheapest clearing is worthless if the data cannot be reconciled into the PSP's ledger. Test the feeds before signing, not after the first month-end.

None of these questions is about impressing a counterparty. They are about knowing where the risk sits, because in a PSP the risk sits in the gap between what is marketed and what each bank actually approved.

The stablecoin shift

The banking conversation is changing as stablecoins move into the settlement layer. Public reporting over the past two years shows the direction. Stripe acquired Bridge for roughly $1.1 billion in late 2024. Mastercard completed its acquisition of BVNK, a stablecoin infrastructure firm, in August 2026. Circle agreed to buy the Singapore cross-border payments platform Tazapay. A consortium of more than 140 companies — including Stripe, Visa, Mastercard, Coinbase, and BlackRock — launched Open USD in mid-2026. Anchorage Digital's acquisition of Routable in October 2026 followed the same pattern: regulated custody and settlement paired with payment orchestration. Each deal was, at its core, about buying the regulated edge of a money system rather than the token itself.

None of this removes the need for banks. It changes where the bank sits. Stablecoins can move value quickly and cheaply between parties that both hold them, but the on- and off-ramps still run through regulated financial institutions. A PSP that settles merchants in stablecoin still needs a bank to convert the float to fiat, hold safeguarded funds, and provide the reporting and controls regulators expect. The bank relationship does not disappear; it moves to the edge of the system.

Europe is making the same point from the regulatory side. The European Securities and Markets Authority issued an opinion in early October 2026 requiring EU crypto firms to stop services in non-MiCA-compliant stablecoins within three months. Meanwhile, euro-denominated stablecoins such as EURC and AllUnity's EURAU have grown, and Deutsche Bank has publicly said it expects to receive a MiCA custody licence in October 2026 covering, among other assets, USDC, EURC, and EURAU. The pattern is consistent: the token is increasingly a commodity, and the value concentrates in the regulated entities that sit between the token and fiat.

One caution is worth stating. Stablecoins compress settlement time, but they do not remove the back-office problems. FX still happens when a merchant wants local fiat, reconciliation still happens when the ledger must match the bank, and exceptions still happen when a payment fails or is reversed. A PSP that treats the token as the whole answer will simply move its problems one layer down. The durable advantage belongs to whoever can run the token and the fiat leg through one controlled system.

For PSPs, the practical question is how to run both rails at once — card and bank rails on one side, stablecoin rails on the other — with the same reconciliation and risk controls across both. That is harder than it sounds. The two rails have different settlement timing, different chargeback and exception logic, and different compliance obligations. A PSP that treats them as one system with one ledger has an advantage. One that runs them as two silos pays for the overlap in operations and in error handling.

The principle behind it

The lesson generalizes beyond any single bank. A payments provider's real moat is whether a trusted financial institution understands and approves its business model, accepts the responsibility of moving third-party funds, and whether the provider can carry the customer-of-customer risk the bank will not take. A logo or a license on a page says little about any of that.

The same test applies to stablecoin settlement. The moat is not the token or the chain. It is the regulated entities at the edges, the controls around client funds, and the ability to reconcile every movement back to a merchant and a balance.

Where DogPay fits

DogPay applies the same test to itself. The value it provides to merchants depends on the same fundamentals: compliance controls, careful handling of client funds, and the ability to operate within the risk boundaries set by its banking and payment partners. Before onboarding, a merchant should ask any provider — including DogPay — which entities and partners sit behind a given service, in which regions, and how client funds are held. Those answers matter more than the brand on the account.

This content is for informational purposes only and does not constitute legal, financial, or investment advice. Third-party data is cited as accessed. Service availability and figures are subject to change and vary by jurisdiction.

Sources and notes

M&A references (Stripe–Bridge, Mastercard–BVNK, Circle–Tazapay, Open USD, Anchorage–Routable): public reporting as of 2026-10-13; figures and completion dates should be verified against official announcements before publication.

ESMA non-MiCA stablecoin opinion: ESMA, 2026-10-08. Deutsche Bank custody licence: company spokesperson statements reported in September 2026; verify against Deutsche Bank's official confirmation.

The two-bank example is illustrative and does not describe any specific bank or PSP.