Scaling Past the Back-Office Bottleneck

With payment networks like Borderless, adding a rail is a configuration change, not an engineering project. Coverage is no longer the constraint on growth. For our fastest-scaling customers, the new bottleneck is how much volume their back-office teams can track, reconcile and manage.

Every new provider and rail is another ledger to reconcile, another channel of RFIs to track and another set of reports to pull together. Fifteen providers means fifteen of each. In most companies I talk to, all of it lands on a team working out of a shared mailbox, a dozen provider dashboards and an internal tool. That tool has sat at the back of the engineering roadmap since the day it shipped. That's where growth stalls. The market is still there and the product still works, the team just runs out of hours in the day. It's also why you can't fix it by pointing agents at it. Agents need an infrastructure layer to work on first. We got past the bottleneck by turning back-office work into data and context. Agents need the same thing. The rest of this piece is why the back office fragments as you grow, what we found when we measured ours, and what unlocks faster growth.

Why the back office fragments as you grow

Most of a payments business gets more efficient as volume grows. Entering a new market means adapting an existing compliance framework rather than creating one from scratch. Your terms with a provider improve as your volume with them grows. The product you built for one customer sells to the next ten.

Back-office work doesn't behave that way, because the learning in it is fragmented. RFIs arrive as individual cases, each one resolved in isolation, in whichever tool that provider happens to live in. A provider asks why a customer's stated employment doesn't match their stated source of funds. Somebody answers the email. The payment moves. The answer stays in that thread, the next provider's question lands in a different portal, and nothing about the first exchange makes the second one faster. When whoever answered it leaves, everything they knew about those providers leaves with them.

So the volume compounds even though the learning doesn't. Compliance work grows with the number of customer-and-provider pairs you create, rather than with either on their own. Every counterparty you submit to a new provider is a fresh set of questions, and the answers you previously gave don't travel. We've seen businesses get separate information requests from multiple providers for the same onboarding, asking for overlapping documents, time and time again.

Reconciliation grows the same way, one more ledger to compare against your own for every provider you add, each with its own file format and its own idea of when a payment is final. Reporting grows with it, because a question as simple as how much went to Mexico last week, and how much of it failed, now has to be answered from as many exports as you have providers on that corridor. Scaling means adding customers and providers at the same time, so the work multiplies while the team stays the same size.

The back office has been the target of every automation wave in financial services for decades, and it's still where the people are. At Wise and Monzo, roughly two thirds of all staff work in servicing and operations. JPMorgan's consumer bank runs over 50,000 operations specialists and hires 8,000 a year to hold that number. Over the last five years the count still grew 13% while volume grew 25%, and that was with the process automation the bank credits for much of the gain. SWIFT puts the industry's spend on investigating payments that didn't land as expected at more than $1.6B a year. It also says a single investigation still eats 200 hours of labor across the institutions involved, and that the figure hasn't moved in five years. That labor is the whole back office, reconciliation, reporting and chasing late payments as much as compliance requests. Each generation of software made the person handling the queue faster. It never made the queue shorter, because every item still showed up as if it was a fresh one-off in a tool with no memory of the last one.

What the bottleneck looks like when you measure it

Two months ago we started treating RFIs as structured cases instead of email threads, and running reconciliation daily with overlapping time intervals, looking for asynchronous changes to payments. We also put a clock on every payment that reflects the rail it's on, and started watching every rail for degradation and alerting on downtime. Here's what showed up.

RFIs

In the first eight weeks, 74% of the requests that came in carried a reason we could read. Of those, 94% of those asked for something the client could have supplied at onboarding. One provider's single template, sent to customers of a single platform, made up 39% of every RFI we received, because the same internal contradiction sat in each record. The same contradiction sits in nearly 8% of that platform's customer records today, each one waiting to trigger the same request.

Nobody working that inbox could have produced that finding. Each of those requests looks like a one-off when it lands, and the person answering it is measured on how fast they clear the queue. The pattern only shows up once the cases are data. Once you can see it, you stop answering the same question dozens of times and fix the field on the onboarding form instead.

Reconciliation

Reconciliation is where the asynchronous things happen. A payment settles, everyone stops looking at it, and days later something changes. The receiving bank returns the funds a week on, or a provider cancels a payout it had already reported as sent. So the daily pass re-checks the past seven days, the weekly pass the past 30 and the monthly pass the past 90, and a payment that flips states weeks after it settled gets caught by a later, wider pass. The first cross-provider run turned up disagreements that needed a decision, including payments a provider recorded as completed that eventually failed. Those are the cases where somebody gets paid twice, or a beneficiary never gets paid at all, and at a month-end close some of them would have been three weeks old.

Stuck payment monitoring

Late payments are a monitoring problem, and the hard part is knowing what late really means. In August, a six-figure US domestic wire for one client sat in processing past the same-day window that rail normally clears in. We raised it in the provider's shared channel that afternoon and escalated when the answer was slow. The cause turned out to be upstream of the provider, at their wallet infrastructure, and the wire went out before that day's cutoff. Now apply that across more than 130 local rails, all with different settlement times. It's impossible to know what's stuck without first building a profile of each provider and rail pair on the destination's banking calendar and calculating its p95 settlement time. With that in place you can flag a payment as stuck the moment it's past its typical settlement window, instead of finding out when someone complains.

Rail degradation alerts

Rail degradation alerts are a different problem. It's about knowing the moment a provider's rail starts degrading, across every provider you use, and getting that in front of the team fast enough to route payments through a different provider and keep them moving. Most teams find out a rail is degraded when failed payouts have backed up and customers start writing in, because each provider's status lives on its own page and nobody is watching all of them. We put every rail and every provider's status in one place, fed by the provider's own status page as well as the live transaction data of the whole network. When error rates climb on a rail we alert, often before the provider has posted anything on its own status page. From there, moving the corridor to another provider is a routing change, not a deploy.

Reporting

Reporting is what all of that rests on, and the value is a unified data schema. Every provider formats its data differently, so we normalized statuses and failure reasons to the same fields across all of them and put payment status and reconciliation state on the same row. With that in place, you can see what's actually happening across your whole payment operation. Success rates by corridor. Volume moved across each payment method. Which rail, or which user, is generating the failures, and what's working and what isn't. When the data is fragmented across providers, none of those questions has a coherent answer, and the Mexico question from earlier is a day of exports rather than one filter.

We've taken those learnings and productized them into a layer of back-office tools built directly into the Borderless platform, to remove these scaling bottlenecks and unlock faster growth for every customer on the network.

Turning this into a context layer and control plane for agents

Every payments company I talk to already has a cost program aimed at the back office, and agents finally give them a path to it. The banks say so in public. JPMorgan has told investors its consumer bank's operations headcount will fall about 10% over the next five years while volume grows another 25%. Citi is cutting over 20,000 roles by the end of 2026, half of them in technology and operations support. The fintechs are running the same play with less fanfare, through support headcount cuts and cost-per-customer targets.

Before you point an agent at one of those programs, look at the price it has to beat. At a bank, or anywhere already outsourcing, the marginal back-office worker sits in India or the Philippines at a fully loaded cost of roughly $8 to $15 an hour. Agents don't win on the cost of a case. They win on throughput against volume that keeps growing, and on the patterns nobody in the queue can see. Most of these programs are also waiting on the wrong thing.

Model capability stopped being the hard part a while ago. Reading a reconciliation break, comparing the two ledgers and proposing the resolution is well within what a good model does today. What's missing in most payments companies is anything for the agent to act on. The back office lives in a dozen provider dashboards, a shared mailbox and that internal tool at the back of the roadmap. You can't point an agent at that fragmentation and expect it to reconcile across it. There's no interface to drive, just a filing cabinet somebody has to open.

Everything above needed the same few things. A compliance request has to be a case that moves through a defined set of states, rather than a thread somebody remembers to check. When a payment is late, late has to mean something specific, which takes a baseline for that provider on that rail. A reconciliation break needs a short list of ways it can be resolved, so whoever handles it picks one rather than improvising. Statuses and failure reasons have to mean the same thing across every provider before they can be compared. All of it has to sit in one place that reaches every provider you use, instead of fifteen different logins. That's what got us past the bottleneck, and it's the same system an agent can read and act on, with a result you can audit afterward. The data and context you build for people is the data and context an agent needs. It also buys you the thing agents are best at, which is finding patterns. Normalize the data across every provider and every customer, and an agent can see the same contradiction sitting in hundreds of records, or the same rail failing for three customers at once. Then you fix the cause instead of working the cases one at a time.

As for which agent, I don't think companies will end up running one inside their KYC tool, another inside their ops tool and a third inside finance. The agent that knows your organization and its history is the one you'll want everywhere. That pushes toward one agent vendor plugged into many tools, rather than many tools with agents built in. If that's right, the job of an operations platform is to be something an agent can plug into, whether that agent is Claude, Codex or something you built yourself. I might be wrong and the vertical agents might win but what they plug into is the same either way.

An agent is allowed to get things wrong some of the time. Money movement isn't. Agents are probabilistic. Payments have to be deterministic. The way to have both is an infrastructure layer where the agent makes the judgment call and the actions it can take are fixed in advance. That's how you put deterministic guardrails around a probabilistic model. In practice, the agent gets a bounded set of actions. It answers the provider's request from the identity record, or picks a resolution for a break from the list. When a payout runs late against its own baseline, it flags the payment and drafts the note to the provider. When a rail starts failing, it drafts the reroute for someone to approve. It never signs anything and it never moves funds, and the person reviewing its work sees what it did and why, on the same case.

We're running our internal operations on agents today, turning this kind of structured data into an organizational context layer. We run it human in the loop, with an approval on every action. What we've found is that we can process far more transactions and data with agents analyzing and managing and humans approving than with humans running the full loop. The operations layer was the unlock that let us run the agents effectively.

So the bottleneck on a payments program is how much back-office work a team can absorb before something important stops getting done. That number has been roughly fixed for as long as the work has lived in mailboxes, provider dashboards and spreadsheets. It moves when the back office becomes something software can read, which means RFIs as cases with states, payments with deadlines, ledgers that reconcile against each other and statuses that mean the same thing everywhere. Some companies will want someone to run that for them, and some will want the platform and their own agents on top. Either way it's a data problem you can start on this quarter, without waiting for anybody's model to get better. It's also the part of the cost program that has to come first. The companies that start now are the ones with something to hand their agents when everyone else is still handing theirs a login to a dozen dashboards.