Bank Fintech Partnerships
Commercial alignment, governance, integration and accountability
Define the partnership by its activities
A bank and fintech may cooperate in software, distribution, payments, lending or servicing. The word partnership does not establish which entity holds funds, originates credit, makes a decision or answers a complaint. Name the activities, providers, permissions and customer agreements before dividing revenue.
Distinguish a supplier arrangement from joint distribution or a regulated financial relationship. Several patterns can coexist. A fintech delivering technology may not be the financial provider; a bank supplying an account may not control every unrelated platform service. Responsibility needs activity-specific analysis.
Align economics with delivery
Specify remuneration, qualifying events, refunds, clawbacks, losses and costs. Revenue share is not a complete answer to credit losses, fraud reimbursement or customer redress. Accounting and legal responsibility follow their actual frameworks and facts.
Assess volume, risk and concentration together. A partner can deliver fast acquisition while creating high servicing costs or a narrow credit book. Measure mature customer outcomes and financial performance as well as referrals and originations. The partner's forecasts should be tested against relevant evidence.
Integration should preserve business meaning
Link applications, permissions, agreements, instructions and financial records through durable references. Systems can use different internal identifiers and databases, provided their joins are reliable and accessible to authorised staff. One physical database is not universally required.
Define status semantics. A bank's provisional approval and a fintech's ready-to-use label are not equivalent. Timeouts, duplicates, partial execution and conflicting records need enquiry, reconciliation and accountable resolution. Messaging delivery cannot alone prove a financial effect.
Share data under the actual lawful basis, purpose and permissions. Consent is not the only possible basis, and withdrawing an access permission does not automatically erase every required financial record. Restrict downstream access and retention appropriately instead of promising all data disappears instantly.
Governance across firms
Make material decisions executable: who can stop new business, change limits, restore service, communicate with customers and authorise adjustments? Separate incident command from authority for financial remediation. A contract should support the controls and records needed in practice.
The Basel third-party-risk principles provide a scoped bank-risk reference. The FCA's Consumer Duty is a UK conduct example with its own scope and distribution-chain responsibilities. Neither creates a universal rule that one bank pays every complaint merely because its logo appears.
Fictional example: offer approved but not funded
A fintech interface displays an approved loan after receiving the bank's conditional decision. Required contract acceptance is still missing and funds have not been disbursed. Support joins the application, decision conditions and agreement state, corrects the message and investigates affected customers.
The bank and fintech assess responsibility under the actual arrangement and applicable rights. They fix the state transition and test similar cases. Moving the complaint to another logo is not evidence that the customer has been served.
Change and exit
Provider replacement, contract termination and licence changes can affect existing customers. Preserve servicing, complaints, statements, repayments and required records through an authorised transition or run-off. Ending new referrals does not end booked obligations.
Takeaway
Partnership quality depends on clear roles, joined evidence and actions that work across the boundary. Commercial alignment should fund continuing service and correction as well as acquisition.
Continue to Ecosystem Governance & Accountability.