Case study · Payments infrastructure
Owning the roadmap to bring an acquired payment network online for tens of millions of cardholders, and building the guardrails that held authorization performance steady while the rails changed underneath them.
If you read nothing else
A top-tier US card issuer bought a payment network so it could bring card processing in-house and stop renting the incumbent networks' rails. The prize was the economics. The risk was that moving tens of millions of cardholders onto new rails is exactly the kind of change that makes good cards start getting declined. I owned the roadmap to bring the network online, and the guardrails and monitoring that held authorization rate within ±20 basis points while it happened. The point was for the people using the cards to feel nothing at all.
Every so often a card issuer decides to stop paying the toll. The big networks sit in the middle of every swipe and take a fee, and an issuer large enough to own a network of its own can bring that processing in-house and keep the spread. The strategic case writes itself, and it is the part that makes the headlines. The part that does not is that the rails being swapped are live, the cardholders riding on them have no idea anything is changing, and they should have no idea. I owned bringing the acquired network online, and my real job was the second half of that sentence: making the swap invisible to the person at the register.
A payment network migration is one of the most dangerous things you can do to a working card portfolio, because every layer that makes a card function has to be re-pointed: the identification numbers that route a transaction, the credentials merchants have stored for recurring payments, the acceptance footprint, the authorization path itself. Get any of it wrong and the failure does not show up in a strategy deck. It shows up as a person standing at a checkout with a card that should work and does not. The quietest version is the card on file: when a number changes, a credential a merchant stored months ago goes stale, the next recurring charge comes back as an invalid card, and a subscription a cardholder set up and forgot about simply stops, with no warning to them and no retry that can fix it.
Authorization rate is the single number that captures whether that is happening, and across tens of millions of cardholders, a few basis points is a lot of real people having a bad moment they did nothing to cause. The economics were the reason to do the migration. Authorization rate was the thing that would quietly tell us whether we were breaking the customer to get them.
The economics live in a deck. Whether it worked lives at a checkout counter, in the half second before a card is approved.
Everything on the bottom layer changed at once. The top layer could not be allowed to change at all. The guardrail in the middle is the part that kept them apart.
The bet was to treat authorization rate as the release gate, not a report. Rather than migrate to a calendar and measure the damage afterward, I made a tight authorization tolerance, ±20 basis points, the thing that decided whether the rollout moved forward, paused, or rolled back. The migration advanced in stages small enough that if performance drifted outside the band, we could see it at once and reverse it before it reached scale.
What I chose not to do was the big-bang cutover the synergy math quietly wanted. Moving everything at once books the economics fastest, and it is also the version where, if anything is wrong, tens of millions of cardholders find out in the same hour. I also chose not to run the migration on a fixed schedule that treated authorization rate as a number to review in the retro. The senior call was to let the customer-impact metric govern the pace of the business win, even when that meant going slower than the economics wanted to go.
The rule was simple: the migration moves at the speed the authorization rate says it can, not the speed the synergy wants.
The guardrail only worked because everyone agreed to be bound by it before we started, and getting that agreement was the actual job. The economics and network teams were measured on volume moved. Risk and operations were measured on nothing breaking. The customer-facing teams were measured on call volume and complaints. Left alone, those incentives pull a migration toward either reckless speed or permanent caution, and the loudest voice in the room usually wins.
So instead of arbitrating each decision in the moment, I put the decision into a number everyone had already signed off on. The ±20 basis point tolerance, the staged sequence, and the rollback triggers became one shared definition of done that the volume side and the safety side had both agreed to in advance. When authorization performance held, the rollout earned the right to accelerate, which gave the economics team their speed. When it drifted, the rollout paused on its own, which gave risk their safety, without a meeting and without a fight. My work was less making the calls than designing the system that made the calls, so a high-stakes migration ran on evidence instead of on whoever argued hardest.
The network came online and authorization rate held within the ±20 basis point band through the rollout. For the people using the cards, that is the entire result: the thing they would have noticed is the thing that did not happen. The economics the acquisition was built on depend completely on the migration not breaking the customer, and the guardrail is what let the business move toward the prize without trading the cardholder for it. Honest attribution: the rails were rebuilt by a large engineering and network organization, and my part was owning the roadmap and making authorization performance the gate everything else had to clear.
What I would do differently
I built the guardrail around the metric I could see in real time, authorization rate, and that was the right anchor. What I underweighted early was the part of the experience that an authorization rate cannot see at all: a card that authorizes perfectly but is not accepted everywhere the cardholder expected it to be. A lot of that lives outside the bank's walls, in merchants and terminals and stored credentials, which is exactly why it is easy to leave off the dashboard. I would instrument the gap between "authorizes" and "works the way the customer expected" from day one, and treat that gap as part of the release gate, not something you learn about later.
A migration like this is judged by what the customer felt. The best outcome is that they felt nothing, and nobody claps for the decline that never happened.
The vertical-integration move behind this is now reshaping the whole card industry, and more issuers will face the same swap: bring the network in-house, capture the economics, and somehow not make the customer the one who absorbs the transition. The part most of them will underbudget is the part I spent mine on: the discipline of holding the experience perfectly still while the foundation moves under it. Protecting the person at the checkout from a change they never agreed to and should never notice is the part of payments I care about most, and the part that does not get a press release.