Who owns the data in a partner bank model

If your sponsor bank ended the relationship tomorrow, could you produce a list of every end customer and the balance they are owed, from records you control and can defend, inside a week? The quick answer is usually yes. The slower answer starts with a list of the systems you would have to pull it from, and it is the slower answer that matters.

That question stopped being theoretical in April 2024, when Synapse Financial Technologies, a US banking-as-a-service middleware firm, filed for bankruptcy. End users of several fintech apps lost access to their funds for months while the parties tried to work out whose records were right. We used it as context in our first post, on reconciliation. It is still the clearest argument for settling these questions while everyone is friendly. The legal detail of that case belongs to lawyers. The operational lesson is plain enough: when several parties each hold part of the picture, nobody can pay customers until the parts agree.

Which ledger is the ledger of record

In a typical partner bank arrangement, the money sits in a pooled account at the bank. The bank's core system knows the balance of that account and very little else about your customers. The individual balances, meaning what each end customer is owed, live in a sub-ledger run by the fintech, its program manager or a middleware platform. A card processor often holds a third view, covering authorizations and holds that have not settled yet.

Contracts usually say the bank's records are the ledger of record. In practice the bank's records show one number for the pooled account, and the per-customer figures come from a file you send, when you send one. The label is attached to data the bank did not produce and may never have checked. That works as long as somebody proves every day that the sub-ledger adds up to the pooled balance, and as long as the bank holds a copy of the sub-ledger it could read without your help.

So pin down who produces the per-customer file and how often the bank receives it. Daily is the least we would accept. Name the team that compares the total of the individual balances against the pooled account, and agree what happens when the two numbers differ: who investigates, within how long, what tolerance passes without comment, and at what size or age a break goes to the bank's own operations team. Put the timings into the service levels with a measurement point both sides can see, along the lines we described in service levels your partners can actually measure. If the current answer is "we would call our relationship manager", write down what that call is supposed to achieve.

A contract that names a ledger of record without naming the file that feeds it has settled the argument on paper only.

Customer data has more than one owner

The word "ownership" in a data clause does less work than people expect. The bank is the regulated account provider, so it will want access to identity records and transaction history whatever the contract calls the data. The fintech holds everything around the account: app activity, support conversations, device information, marketing consent, the enriched merchant names customers actually recognize. Some of that the bank will never ask for. Some of it, complaints being the obvious example, it may ask for on a Friday evening.

A more useful exercise than arguing about ownership is listing rights. Who can access which records, in what format, how quickly, for which purposes, and what happens to every copy when the relationship ends. KYC files are a good test of whether you have done this properly. If the bank relies on your onboarding checks and the relationship ends, who keeps copies of the files? Which side answers a customer's request for their own data? Who deletes what, and on what trigger?

What to put in the contract

Most of this belongs in the program agreement or its schedules, where neither side can change it by editing an internal manual. The clauses we look for first:

• The ledger of record for customer balances, the file that feeds it, its format and delivery time, and what the bank does when the file is late.
• Daily reconciliation duties: who runs it, the tolerance, the deadline for investigating a break, and the escalation path to named roles on both sides.
• Access during the relationship, covering the bank's right to query the sub-ledger and your right to the bank's account-level data, including returns, holds and funds frozen at the bank's own initiative.
• Exit and wind-down: a full extract of customer records, balances, transaction history, open disputes and KYC files, in a named format, within a stated number of days, with the costs agreed in advance.
• Failure of the party in the middle. A program manager or middleware platform sitting between you and the bank creates a dependency worth writing down: what the bank can read directly if that party stops operating, and who holds a standby copy.

The last one is the clause most often missing, because it describes a situation nobody at the table wants to discuss. It is also the one that decides how long customers wait for their money.

Test the exit before you need it

Once a year, ask for the extract as though the relationship were ending. Load it somewhere outside production, reconcile the balances to the pooled account on the same date, and time the whole exercise. Then ask the bank to rebuild a sample of customer balances from its own records without your help, and see how far it gets.

The first attempt will be slow, and most of what you learn will be about file formats, missing fields and which person at the bank knows where the data lives. That is the point. Finding out on an ordinary Tuesday in May costs you a day of work. Finding out during a wind-down costs your customers access to their money, and costs you the explanation.

Discuss your operations