"Liability is also reputation."
That was Kyle Hauptman, Chairman of the National Credit Union Administration, at a Fintech Meetup panel this year. He was making a point about retailer data breaches and the debit card reissues that follow them, where the retailer causes the breach but the customer ends up blaming the bank.
"It doesn't matter what you say. They think they're the problem."
When the institution is the one at fault, Kyle put the bar in the same place:
"I want them to communicate just as directly as when they're trying to sell something to you... We screwed up. We are the problem."
The moderator on stage, Louise Beaumont, framed herself as the commerce voice in the conversation, "red in tooth and claw" alongside two regulators. The question she put to the room was: what does it take to make open banking safe enough to work at scale?
The same question, in our experience, lives one layer down for lenders. What does it take to make a payments stack safe enough to work at scale?
Most lenders we work with at IPG haven't asked it that way. They should. The dynamic Kyle was describing governs their entire payments operation, from the rails up through the disbursements and retries the borrower experiences directly.
When a borrower's first disbursement fails, or a payment plan can't recover from a single declined transaction, or a fee structure wasn't visible at the point the borrower agreed to it, the lender is the only counterparty the borrower can see. The processor, the gateway, and the vault that holds the borrower's payment data are all invisible from where the borrower sits. What the borrower sees is the lender's logo on the disbursement and the lender's name on the email, so whatever happened underneath, the lender owns the conversation that follows. That is reputational liability in Kyle's sense, and it lives entirely with the lender.
What we see in a payments diagnostic when the underlying layer hasn't been built is a chain of small failures that compound. A first disbursement retries into the next business day, and the borrower assumes the funds aren't coming and applies somewhere else. A repayment fails an R01 NSF, the lender treats it as a soft decline, retries on the same day, gets another return, the borrower's bank flags the activity, and the borrower closes the account. None of these are crises in isolation, but together they show up in the lender's portfolio numbers without any obvious cause attached.
Across the lender stacks we audit, a vendor token gives a lender about nine data points on a borrower's payment history. A vault the lender owns gives twenty-one. Twelve data points is the difference between a lender who can see why a transaction failed and a lender who can't. That gap shows up downstream as false declines the lender doesn't recognize as false, R01 NSF returns that get treated like soft declines because the underlying account state is invisible, and retry strategies firing on a fixed schedule because there is nothing smarter to fire on.
A single-processor setup gives the lender no waterfall and no redundancy. The structure we typically deploy uses five to seven processors with intelligent routing. Approval rates lift ten to thirty percent before any other change. The borrowers and the loans are unchanged, and the lift comes entirely from the authorization signal the lender now controls.
VAMP-era chargeback monitoring is a function of which processors the lender selects, R01 NSF visibility is a function of whether the lender owns the vault or rents the token, and multi-rail collections across ACH, debit, credit, and alternative rails is a routing logic decision that either lives with the lender or doesn't. These are not payments-vendor questions but infrastructure ownership questions, and the lender owns the consequences either way.
The chain has four layers. Legislators write the law. Regulators turn the law into rules and convene the institutions that operate under them. The market builds and operates the connections: the APIs, vaults, monitoring, and liability allocation. The institution carries the consequences when something fails. The first three layers exist so the fourth one is not carrying everything alone.
Louise Beaumont named the regulator's limit on the panel:
"You cannot be inside every API call. You can't be that risk management layer accrediting the fourth or fifth or nth level party, that continuous monitoring, that liability allocation that doesn't leave the credit union or the bank holding all of that risk. I would argue that's a role for the market."
Kyle Hauptman made the property argument behind it:
"That is my property just as much as the cash sitting in the account."
A bank holds a customer's deposits on the customer's behalf, and the customer's payment data sits in the same relationship: held by the institution, owned by the customer. Liability has to be allocated to match that reality, not defaulted onto the financial institution because the rules haven't caught up. Until that shifts, the market can't take on the role Louise was describing, and the financial institution carries everything.
Jessica Rusu named the protection bottom line:
"Consumers expect to be protected. That's the bottom line."
That protection starts from whose information it is. The borrower's financial information belongs to the borrower, and the institution that holds it is accountable for what happens to it.
Data minimization is the consumer-protection principle Jessica Rusu named on the panel: share what needs to be shared, not more. It is meant to constrain what a vendor sees, not what the institution holding the borrower relationship sees. The vault that holds the full picture of the borrower's payment behavior should sit with the entity that carries the consequences, and when the lender rents a token instead of owning a vault, the lender ends up minimized too.
In payments, the borrower's payment data belongs to the borrower, and whether the lender holds it directly through an owned vault or rents access through a vendor token, the call still comes to the lender.
Most lenders haven't filled that market role for their own stack. They have a processor relationship and a handful of gateway integrations, a vendor token they have never inspected, and no one inside the company whose job is to monitor the chain end to end.
Jessica Rusu put the infrastructure point in aviation terms on the same panel:
"You don't want airplanes flying around with no air traffic control. The infrastructure layer creates the API standards, the data integrity standards, the sharing standards. That is the air traffic control layer that needs to be architected."
Processors, gateways, vaults, and routing logic are the air traffic control for the lender's money movement. Most of the lenders we audit are using whoever they signed with first or whoever their LMS pointed them to, with no waterfall, no redundancy, and no view of what is happening on the rail underneath.
The conversation we have with a CFO or a head of payments at this stage usually goes the same way. They know they have a processor. Beyond that, the contract terms with the gateway, whether the token gives them PAN-level data or just a reference, how R01 returns are categorized, what their false-decline rate is: none of those are visible inside the lender. The first deliverable on every IPG engagement is showing the lender what is already in their stack.
Louise's question, asked of a lender's own stack: who built the chain you are running on, who monitors it, where does liability land when something goes wrong, and what would change in your authorizations, retries, and disbursements if you owned the layer your processors sit on top of?
Most lenders we work with would rather answer those questions on their own terms now, with a partner whose entire job is to build and operate that layer, than have them answered later by a borrower complaint or a regulatory inquiry.
When the payment fails and the borrower picks up the phone, no one from the processor is on the call. The lender is. That is the liability Kyle was talking about, and it sits with the lender. The infrastructure underneath should sit with the lender too.
Send the file. We will tell you what we see.
Watch the Fintech Meetup panel