The Myth of the Global Payment API

2.1 Jurisdictional hard borders

A UK open banking API cannot trigger a Brazilian Pix payment. A SEPA Instant transfer cannot settle into a FedNow account. UPI cannot push rupees onto Canada's Interac rail. These systems are domestic utilities: operated or mandated by domestic central banks, denominated in domestic currency, governed by domestic law, and open exclusively to domestically regulated entities.

Even inside a single country the picture fragments. The United States runs two instant-payment schemes that do not interoperate with each other, and between them they still reach only a fraction of the country's roughly 9,000 depository institutions.

The exceptions prove the rule. Corridor linkages such as UPI-PayNow (India and Singapore, 2023) are bilateral treaties in software form: each one took years of central-bank negotiation to produce a single corridor. The BIS's Project Nexus, the most serious attempt at multilateral linkage of instant payment systems, exists precisely because the fragmentation is otherwise permanent, and it is still years from carrying meaningful live volume. Nobody builds a global product one treaty at a time.

2.2 The broken metadata layer

Modern software runs on reliable data passage. An invoice ID attached to a payment is what lets a ledger reconcile itself. Yet the payment systems of the world treat remittance data as an afterthought, and three independent failure modes destroy it in transit:

1. 1.The fields are tiny. A SWIFT MT103 carried remittance information in field 70: four lines of 35 characters, 140 characters total. A SEPA credit transfer allows 140 characters of unstructured remittance data. A standard US ACH entry carries one optional 80-character addenda record. Some domestic rails allow less than 20 characters of reference. These limits were set for humans reading paper statements, not for structured machine data.
2. 2.The customer can edit them. When an API hands a user off to their own bank to authorize a payment, the bank's user interface decides whether the reference field is editable. In most retail banking apps it is. A payer can clear it, mistype it, or overwrite it with "rent lol," and the receiving system's reconciliation logic silently breaks.
3. 3.The rails mutilate them. Downstream clearing systems and intermediary banks routinely strip special characters, truncate strings, and drop non-mandatory fields to fit legacy core-banking schemas. Data that leaves intact does not reliably arrive intact. ISO 20022 was designed to fix this with rich structured remittance blocks, and it genuinely helps, but a standard is only as good as the least-upgraded system on the path, and the world's banks will be running mixed infrastructure for years.

The cost of this broken layer is not cosmetic. When money and the order it belongs to arrive as two unrelated events, someone has to match them by hand: back offices around the world run entire teams whose only job is re-attaching payments to the obligations they were meant to discharge.

2.3 The manual entry tax

Everything above assumes the payment at least launched with correct data. On today's non-API transfers, that assumption fails at extraordinary rates, because the interface of a bank transfer is still a human being transcribing identifiers into a form. An IBAN runs up to 34 characters. A BIC is 8 or 11 more. A US routing-and-account pair is 17-plus digits, and on most legacy rails nothing checks those digits against the beneficiary's actual name before the money leaves. The sender types all of it on a phone, copying from an invoice, a PDF, or a chat message, and the receiving side often re-keys it again into its own systems.

The damage is not anecdotal; it is measured. Accuity's global study of failed payments, the research behind the USD 118.5 billion annual cost figure, found that account number issues caused one third of failed payments and inaccurate beneficiary details caused another third. Roughly two thirds of all bank transfer failures trace to bad account or beneficiary data, and the bulk of that data is bad because a human keyed it. LexisNexis Risk Solutions' follow-up True Impact of Failed Payments report confirms the pattern: beneficiary name and address problems are the single most common source of payment delay or failure, 72 percent of organizations still verify beneficiary details manually, and each failed payment carries an average USD 12 in repair fees before counting the delay, the support burden, and the customer attrition.

The rails' own response is telling. The UK bolted Confirmation of Payee onto Faster Payments, and the EU's Instant Payments Regulation made Verification of Payee mandatory from October 2025, both systems that check a typed name against the destination account and warn the sender before release. These are worthwhile mitigations, and they are also an institutional admission: the entry layer is so unreliable that the system now interrupts the human to ask whether they typed the truth. The warning still depends on the human reading it, and the human still types. No amount of verification theater changes the underlying design, in which the least reliable component in the entire payment chain, a person transcribing digits, is assigned its most critical task.

2.4 The aggregator patchwork

Fintechs have responded rationally to this fragmentation: they buy it down through aggregators. Plaid, Tink, TrueLayer and their peers maintain software wrappers over thousands of individual bank integrations and resell them as one API document.

This is valuable work, and this paper does not dismiss it. But it is essential to be precise about what aggregation is: translation, not control. An aggregator normalizes dialects; it does not own the grammar. Three consequences follow:

• Coverage is read-heavy. Reading balances and transactions is broadly solved. Initiating payments is available only where a domestic regulatory regime mandates it (the UK and EU), and even there only on that region's domestic rails.
• Capability decays at every border. The moment a transaction becomes cross-border or cross-currency, the aggregator's illusion of unity shatters, because no domestic mandate reaches across the trench.
• The last mile still belongs to the bank. The aggregator cannot lock a remittance field, cannot choose the rail, and cannot guarantee what the customer's banking app will let the customer do at the moment of authorization.

Aggregators unified the windows into the banking system. Nobody has unified the doors.

3.1 SWIFT does not move money

The most important technical reality: SWIFT is a secure messaging cooperative. It holds no deposits, operates no settlement accounts, and moves no value. It passes structured financial instructions between banks, historically the MT message family, and since 22 November 2025 exclusively ISO 20022 (MX) for cross-border payment instructions, the MT103 and MT202 having been formally retired at the end of the coexistence period. The message instructs Bank A to debit an account and Bank B to credit one; the value itself moves across correspondent account relationships (nostro and vostro balances) between the banks.

Because SWIFT holds no money, there is no such thing as "calling the SWIFT API to pull funds from a customer." A payment must always originate from inside a bank that has a gateway to the network and a correspondent path to the destination.

3.2 The APIs SWIFT does offer are not initiation APIs

SWIFT has modernized aggressively, and credit where due: gpi gave every payment a unique end-to-end reference (UETR) and a tracker, and SWIFTRef exposes clean routing reference data. But these are tracking and validation surfaces. They tell you where a payment is; they do not let an outside developer create one. There is no public, open-banking-style API through which a third party can write a payment instruction onto the SWIFT network. Membership, supervision, and a banking relationship stand in front of every message.

3.3 The corporate workaround is not an API either

Large multinationals do achieve automated wires, and the machinery they use is instructive precisely because of how heavy it is: host-to-host (H2H) integrations or SWIFT service bureaus, negotiated bilaterally with specific treasury banks; dedicated security certificates and hardware; months of legal onboarding and compliance vetting; and rigid maker-checker workflows in which one system or human prepares a payment file and a separate authorized human approves its release. This is real automation, but it is artisanal, per-bank, per-contract automation, available to corporate treasuries with seven-figure banking relationships. It is not open to the public, and it is nowhere near a clean API call.

The conclusion of this section is stark: for an ordinary merchant or fintech, there is today no public programmatic path to an automated international wire that removes manual data entry for both sender and receiver. That capability has been locked inside bank ledger networks since the day those networks were built.

5.1 The anatomy of a session

The unit of work in the Commtrac API is the checkout session. One request opens it:

The request carries the merchant, the order, the exact amount, and a trac_set: an instruction set stating what type of checkout session it is, and what it should do.

The response is a hosted checkout URL, generated fresh on every call. The customer follows it, searches for and selects the institution they bank with, and authenticates inside their own bank. There is no app to install, for the customer or the merchant; Commtrac is appless infrastructure by design. Nothing sensitive is ever entered on the merchant's site, and the merchant builds and stores none of it. The customer simply logs into their bank, on the bank's server, and authenticates Commtrac to complete the approved transfer for them.

It takes the "scary" data entry and complexity out of a payment, and reduces it to: sign in here. That is all the customer has to worry about. The Commtrac API transforms every aspect of banking that traditionally relies on probabilistic outcomes (a customer entering banking information, a merchant wondering whether a payment has been initiated, or whether a payment memo was copied correctly) into a deterministic, machine-executed workflow.

Notice what this structure did to the compliance problem. The moment of truth, where a human proves who they are and approves a movement of their money, happens inside a regulated bank's own authentication flow, under that bank's own security, subject to that bank's own screening. Requirement 2 and requirement 3 from Section 4 are satisfied not by a clever workaround but by never violating them. It was solved by paying attention to what is already so obviously there. It never required sci-fi, convincing parliament, or asking banks to let their guard down. It was solved by turning 1s and 0s into a customer/merchant intent within a checkout URL, and executing that intent with reliable automation and efficient engineering.

5.2 The rail is a parameter

Section 2 established that the world's rails are islands. The Commtrac API's answer is to make the rail a field in the request body rather than an integration project.

The merchant states which rail it accepts by setting a payment_code. Commtrac resolves that code against the region the customer banks in and initiates on the matching rail:

• LOCALRT resolves to the customer's domestic real-time push rail (e.g. in Canada, an Interac e-Transfer leaving the customer's own bank).
• FXSWIFT resolves to a wire across the SWIFT network, originating, as every wire must, from within the customer's own bank.
• FXELECP resolves to an EFT pull against the customer's account, authorized by the customer.

One integration, held once, replaces the per-country, per-scheme, per-bank matrix documented in Section 2. The merchant does not integrate Interac, or Faster Payments, or SEPA, or a wire desk. The merchant states an intent; the customer's bank executes it on the rail that exists where that customer lives.

This is also the honest resolution of Section 3's dead end. There is still no public API that writes onto SWIFT from outside the banking system, and Commtrac does not pretend otherwise. Instead, the wire originates where wires have always had to originate, inside the sender's bank, with the sender authenticated and approving. What Commtrac removed is everything that made that unusable as software: the branch visit, the form, the transcription of a 30-character account path across a phone screen, the unstructured reference, and the silence afterward. The instruction is assembled programmatically, approved by the customer in their banking session, and confirmed back to the merchant as a machine-readable event.

5.3 Data that survives the journey

Section 2.2 documented the three ways remittance data dies: tiny fields, editable fields, and destructive rails. The Commtrac API attacks the failure that matters most, tampering and loss at the point of authorization, with a blunt guarantee: the merchant writes the reference, and the customer cannot touch it.

The merchant injects its own structured data into the bank payment itself: invoice numbers, order references, ledger keys, whatever the back office matches on. Commtrac understands each bank's memo limits, and writes it into the payment's message field and locks it, so the customer cannot edit, clear, or overwrite what was set. The reference travels bank to bank inside the payment, and what arrives at the receiving account is exactly what the merchant wrote.

The consequence for reconciliation is structural, not incremental. The credit and the order it belongs to arrive already matched. The problem class quantified in Sections 2.2 and 2.3, payments that arrive as orphans and feed the USD 118.5 billion failure bill, is designed out at initiation rather than repaired downstream.

5.4 Verification as a primitive, not a product

Section 4 listed sanctions and AML screening among the reasons banks cannot open their doors. The Commtrac API turns the merchant-side half of that burden into a call.

On the same call that opens a session, the API confirms the legal name and registered address behind the customer's account, verified against the institution where the account actually lives, before value moves. For KYC and AML review this replaces the weakest link in most onboarding flows, self-reported identity, with bank-attested identity. And where a merchant pays out to its own customers, the API returns the verified account behind that customer rather than asking anyone to key in destination details.

The API does not replace a regulated institution's own screening, and is not designed to; the customer's bank still runs its checks and holds its veto. What it does is ensure that everything the merchant contributes to the transaction, identity data and destination data, is verified at source instead of transcribed by hand.

5.5 Link once, pay by confirmation

Payment friction is cumulative: every form field is an abandonment opportunity. The Commtrac API collapses repeat payment to a confirmation. A customer authenticates once; every account they approve stays available to the merchant (TRAC_LINK_ALL), and every future payment is a single confirmation rather than a new form. Customers can link multiple accounts and choose among them.

This matters beyond convenience. It means the expensive, high-assurance event, a full bank authentication, happens once, and the cheap event, an approval, happens per payment. That is the same asymmetry that made card-on-file commerce work, achieved without a card, a token vault, or a stored credential on the merchant's side.

For a customer that does not want to "link their account", and simply wants to pay and leave; merchants can easily route this behavior by using the (TRAC_UNRECK_SEND) trac_set to generate the customer's Commtrac checkout session.

5.6 Native conversion at the moment of initiation

Cross-currency payments on legacy correspondent paths suffer conversion at unpredictable points, at rates set by intermediaries the sender never chose, which is precisely why the G20 cost targets in Section 4 exist. The Commtrac API handles conversion natively, inside the same session that initiates the payment, priced against live interbank rates from tier-one liquidity providers, and metered at a flat 25 cents per conversion.

The structural point is larger than the rate. Conversion at initiation means the sender knows the settlement amount before approving, which is most of what "transparency" means in the G20 targets, and the conversion fee is a fixed, published number rather than a spread hidden inside a corridor.

5.7 Economics that look like infrastructure

The Commtrac API is metered like the infrastructure it is: ten cents USD per API call, twenty-five cents USD per currency conversion, and no platform fee. No percentage of volume, no interchange, no corridor pricing.

Flat metering is not a pricing gimmick; it is a claim about what the product is. Percentage pricing asserts that moving USD 10,000 costs the network a thousand times more than moving USD 10, which is true of risk-bearing intermediaries and false of software. By pricing initiation as software, the Commtrac API makes the marginal cost of a payment effectively invariant to its size, which is what finally makes programmatic, high-value, bank-to-bank flows economically rational for the businesses running them. Against the G20's own end-2027 benchmark, a global average retail cost of no more than 1 percent, a flat dime does not merely meet the target; it makes the target look unambitious.

5.8 What the compliance posture actually is

It is worth restating the posture precisely, because it is the paper's central claim:

• The customer's bank authenticates the customer.
• The customer approves every payment on a Commtrac checkout session. Nothing moves on a merchant's signature alone.
• The bank retains its screening, its risk controls, and its absolute veto over release, exactly as its regulators require.
• The merchant never receives, stores, or transmits account numbers in either direction.
• Sensitive data never has a reason to touch the merchant's frontend, so there is nothing for a client-side bad actor to read.

The "holy grail" API was always described as one that escapes the banking system. Commtrac's position is that this framing was the error all along. The API the world actually needed is one that is welcome inside the banking system: automation that banks can host because it strengthens, rather than bypasses, their control of the perimeter.