Partnership arrangements between chartered banks and technology companies have moved from novelty to infrastructure. A fintech owns the customer relationship and the application; the bank holds the charter, the deposits and the regulatory relationship. The commercial logic is clear on both sides, and so is the concentration of risk.
What is less clear, in many institutions, is where the contract sits and what it says. These agreements are typically negotiated once by a partnerships team, signed, and then filed. Two years later a program has grown well beyond its original assumptions, subcontractors have been added, and the people who negotiated the compliance allocation have moved to other roles.
Supervisory attention on these arrangements has been sustained, and the consistent theme in examination findings is not that banks lack contracts. It is that the contracts do not describe the program as it actually operates, and that the oversight obligations inside them are not being performed. Both are contract management problems before they are policy problems.
The provisions that decide accountability
A small number of terms carry most of the weight in these agreements. Each one should be extracted into the contract record rather than left to be rediscovered during an examination.
- Compliance allocation, a clear statement of which party performs each compliance function, and an acknowledgment that performance by the partner does not relieve the bank of its own obligations.
- Program limits and growth controls, caps on volume, balances or customer segments, with a mechanism the bank can use to pause growth without needing the partner to agree first.
- Data ownership and access, which party owns customer records, in what format they are held, and how quickly the bank can obtain a complete and usable copy on demand.
- Audit and information rights, the right to examine the partner and its subcontractors, plus the recurring reporting the bank will actually receive between examinations.
- Wind-down and transition, what happens to accounts, balances, records and customer communications if the arrangement ends, including who funds the exit and over what period.
The failure pattern is consistent. These provisions are negotiated competently and then never operationalized, so the bank holds rights it has no process to exercise and receives reporting nobody reviews. The gap is not in the drafting; it is in the distance between the executed document and the day-to-day oversight program.
A partnership agreement can allocate who performs compliance activities. It cannot move the bank's own regulatory obligations to the partner. Contracts that read as though responsibility has been transferred tend to attract attention precisely because they suggest the institution has misunderstood the arrangement it is in.
Turning the agreement into an oversight program
The distance between a well-drafted agreement and a defensible program is closed by ordinary contract operations work. Five moves cover most of it.
- Extract the obligations at signature. Every reporting cadence, attestation, notice requirement and review right becomes a dated record with a named owner, not a paragraph in a document in a shared drive.
- Map the subcontractor chain. Partners rely on their own vendors for processing, onboarding and analytics, and the agreement should require disclosure of that chain with notice of material changes to it.
- Test the data right before you need it. Request a full data extract during normal operations to confirm the format is usable. A right exercised for the first time during a wind-down is a right discovered to be theoretical.
- Reconcile the contract to the live program. Compare the products, volumes and customer segments described in the agreement against what the program actually does, on a scheduled cycle rather than after an inquiry.
- Keep amendments in the record. Programs change through side letters and amendments, and an oversight file that reflects only the original executed agreement will not survive examination.
A five-step roadmap for existing partnership arrangements
Step 1, locate and inventory every agreement
Partnership contracts are often held outside the main vendor repository because they were negotiated as commercial deals rather than procurements. Finding all of them, including amendments and side letters, is usually the largest single step and it is worth doing before anything else.
Step 2, extract the control terms into fields
Pull compliance allocation, program limits, data rights, audit rights and termination mechanics into structured data. AI extraction handles the first pass across a portfolio quickly, with review concentrated on the provisions that carry the most consequence.
Step 3, stand up the reporting calendar
Convert every recurring obligation, the partner's reports to you and yours to them, into scheduled tasks with owners and evidence capture. Missed reporting is the most common and most avoidable finding in this area.
Step 4, assess each program against its contract
Score programs on whether the executed terms match current operations, whether limits are being observed and whether the exit plan is executable. The output is a short list of agreements that need amendment rather than a general anxiety.
Step 5, rehearse the exit
Walk through what a wind-down would require for the largest program, end to end. Doing this on paper reveals which contractual rights are missing while there is still leverage to negotiate them.
Put partnership oversight on a contract record
Aavenir extracts control terms, reporting duties and exit provisions from partnership agreements and keeps each one owned, dated and evidenced.
Why these agreements resist normal vendor management
Most banks have a functioning third party risk program, and partnership arrangements still fall outside it. The reason is structural. A vendor sells the bank something and is managed by a procurement-led process with a defined owner, a risk tier and a review cycle. A fintech partner is a revenue partner, negotiated by a business development team, governed by a commercial agreement, and often regarded internally as a customer rather than a supplier. The oversight expectations, however, are closer to those applied to a critical vendor than to a customer, and the risk sits with the bank rather than being shared evenly. Institutions that handle this well stop arguing about which category the relationship belongs in and simply apply the vendor discipline, tiering, extracted obligations, scheduled reporting and a tested exit plan, to arrangements that were never procured. The mechanics are the same ones described in third party risk contract automation.
Control terms and what each one requires operationally
The provisions below are the ones examiners most often ask about, together with the operational artifact that demonstrates each is working rather than merely written.
| Provision | What it should say | Operational evidence | Common gap |
|---|---|---|---|
| Compliance allocation | Named functions by party | Current responsibility matrix | Matrix predates program changes |
| Program limits | Volume and segment caps | Monitoring against caps | Limits never measured |
| Data rights | Ownership and extract format | Tested extract on file | Right never exercised |
| Audit rights | Partner and subcontractors | Completed review reports | Subcontractors not covered |
| Wind-down | Timeline, funding, customer notice | Rehearsed exit plan | No funding mechanism |
The useful question to ask about any partnership arrangement is not whether the contract is well drafted. It is whether anyone could produce, this afternoon, the current allocation of compliance duties, the program limits in force, the last four reports received from the partner, and a wind-down plan that has been tested against the data rights actually held. Institutions that can answer are rarely the ones with the longest agreements. They are the ones that treated the executed contract as the beginning of an oversight program rather than the end of a negotiation. None of this requires a new framework, only that the partnership file be held to the same standard as any other critical supplier relationship and reviewed on the same cycle. For the examination-facing view of the same portfolio, see the third party risk exam checklist.
For related guidance, see Vendor contract repository for banks, at a glance, OCC and FFIEC vendor oversight, the contract controls and The bank’s guide to DORA ICT third-party contract terms.
