If your team is negotiating data access terms with banks or third-party providers under evolving open banking frameworks, you need a contract structure that addresses regulatory uncertainty, liability allocation, and operational controls before the first API call goes live.
This template provides a starting framework for bilateral data access agreements between financial institutions and third-party service providers. It's designed for U.S. institutions navigating the uncertain Section 1033 landscape and EU entities preparing for PSD3, which could launch in 2027.
Purpose of This Template
Use this agreement when your institution shares consumer financial data with a third-party fintech, aggregator, or service provider through APIs. The template covers:
- Scope of permissible data access and use
- Security and authentication requirements
- Liability and indemnification for data breaches or misuse
- Compliance obligations under current and anticipated regulations
- Fee structures for data access
- Termination rights and data deletion protocols
The agreement assumes API-based access, not screen scraping. If you're still allowing credential-based access methods, stop. PSD2 mandated APIs specifically because screen scraping creates unacceptable fraud and privacy risks.
Prerequisites
Before customizing this template, verify:
- Regulatory Classification: Determine whether the third party qualifies as a payment initiation service provider, account information service provider, or another category under your jurisdiction's framework.
- Data Inventory: Document exactly which data elements the third party will access (account numbers, transaction history, balances, personally identifiable information).
- Authentication Mechanism: Confirm your API supports Multi-Factor Authentication for third-party access.
- Liability Insurance: Verify the third party maintains cyber liability coverage adequate to the data exposure.
- Compliance Posture: Review the third party's AML program, sanctions screening capabilities, and incident response procedures.
If you're a bank working with a middleware provider that serves multiple fintechs, you need separate agreements at each tier. The Synapse collapse, which left approximately $85 million in customer funds frozen due to inadequate documentation of money flows, highlighted the risks of unclear contractual accountability.
The Template
OPEN BANKING DATA ACCESS AGREEMENT
This Agreement governs access to consumer financial data between:
DATA PROVIDER: [Financial Institution Name]
DATA RECIPIENT: [Third-Party Service Provider Name]
EFFECTIVE DATE: [Date]
1. SCOPE OF DATA ACCESS
1.1 Permitted Data Elements
The Data Recipient may access the following consumer data categories through Provider's API:
[ ] Account balances (current, available)
[ ] Transaction history (specify retention period: ___ days)
[ ] Account holder name and contact information
[ ] Account numbers and routing information
[ ] Pending transactions
[ ] Other: _______________
1.2 Access Method
All data access must occur through Provider's designated API endpoints using OAuth 2.0 or equivalent authentication protocol. Credential-based access (screen scraping) is prohibited.
1.3 Consumer Authorization
Recipient may only access data for consumers who have provided explicit, informed consent through [describe consent mechanism]. Consent must be renewable and revocable at any time.
2. SECURITY AND TECHNICAL REQUIREMENTS
2.1 Authentication
Recipient must implement Multi-Factor Authentication for all personnel accessing Provider systems or consumer data.
2.2 Data Encryption
All data in transit must use TLS 1.2 or higher. Data at rest must be encrypted using AES-256 or equivalent.
2.3 Access Logging
Recipient must maintain audit logs of all data access events for a minimum of 12 months, including: timestamp, user identity, data elements accessed, consumer identifier.
2.4 Rate Limiting
API calls are limited to [specify: calls per minute/hour]. Recipient must implement retry logic with exponential backoff.
2.5 Penetration Testing
Recipient must conduct annual penetration testing of systems that store or process Provider data. Results must be shared with Provider within 30 days of completion.
3. REGULATORY COMPLIANCE
3.1 Current Obligations
Recipient represents it maintains compliance with:
- [If EU/UK: PSD2 and applicable national API standards]
- [If US: Section 1033 requirements if/when finalized]
- [If applicable: Bank Secrecy Act, OFAC sanctions screening]
- [Data protection: GDPR, CCPA, or equivalent]
3.2 Regulatory Changes
If Section 1033 is vacated or substantially revised, or if PSD3 introduces new requirements, parties will renegotiate terms within 90 days of regulatory clarity.
3.3 Suspicious Activity Reporting
Recipient must file Suspicious Activity Reports for transactions meeting BSA thresholds. Recipient may not disclose to consumers that a SAR has been filed.
4. LIABILITY AND INDEMNIFICATION
4.1 [Data Breach](/glossary/data-breach) Liability
Recipient is liable for [Account Data Compromise](/glossary/account-data-compromise) resulting from Recipient's security failures, including: notification costs, credit monitoring, regulatory penalties, and consumer damages.
4.2 Indemnification
Recipient indemnifies Provider against claims arising from: (a) Recipient's unauthorized use of data, (b) Recipient's violation of consumer privacy rights, (c) Recipient's failure to implement required security controls.
4.3 Insurance
Recipient must maintain cyber liability insurance of minimum $[amount] per occurrence, naming Provider as additional insured.
5. FEES AND PAYMENT TERMS
5.1 Access Fees
[Option A: No fee for data access]
[Option B: Recipient pays $[amount] per [API call / consumer account / monthly active user]]
5.2 Payment Schedule
Fees are payable [monthly/quarterly] within 30 days of invoice.
5.3 Fee Adjustments
Provider may adjust fees with 180 days' written notice. Recipient may terminate if fees increase more than [20]% in any 12-month period.
6. TERM AND TERMINATION
6.1 Term
This Agreement remains in effect for [specify period] and renews automatically unless terminated.
6.2 Termination Rights
Either party may terminate with 90 days' written notice. Provider may terminate immediately if: (a) Recipient suffers [Account Data](/glossary/account-data) Compromise, (b) Recipient violates security requirements, (c) Recipient's regulatory authorization is revoked.
6.3 Data Deletion
Within 30 days of termination, Recipient must delete all Provider data and certify deletion in writing.
7. DISPUTE RESOLUTION
Consumer disputes regarding real-time payment transactions or data access errors will be resolved according to [specify process]. Recipient acknowledges that real-time payments on RTP Network and FedNow currently offer no chargeback or dispute rights.
SIGNATURES:
DATA PROVIDER: _______________ DATE: _______
DATA RECIPIENT: _______________ DATE: _______
Customizing the Template
Section 1.1: List only the data elements the third party genuinely needs. Don't grant access to transaction history if the use case only requires balance checks. Tighter scoping reduces your exposure if the relationship sours.
Section 2.5: If you're the data provider, require the recipient to use your preferred penetration testing firm. If you're the recipient, negotiate the right to use your existing security assessor.
Section 3.2: This clause matters because regulatory clarity remains elusive. The CFPB could vacate Section 1033 entirely or substantially revise it. Build in a renegotiation trigger rather than letting the agreement drift into non-compliance.
Section 5.1: Fee structures are contentious. If you're a bank considering fees, specify whether you're charging per API call, per consumer account, or per active user. If you're a fintech, negotiate caps and ratchets. A fee structure that scales linearly with your user base could threaten your business model.
Section 7: Real-time payment limitations are a hard constraint right now. RTP and FedNow don't support payment disputes or requests for funds. If your use case involves merchant payments or any scenario where the sender might need recourse, real-time rails aren't viable yet. Document this limitation explicitly so both parties understand the operational boundaries.
Validation Steps
After customizing the template:
- Legal Review: Have your in-house or external counsel review the liability allocation, indemnification scope, and insurance requirements.
- Technical Validation: Confirm your API documentation and authentication flows match the technical requirements in Section 2.
- Regulatory Alignment: Cross-reference Section 3 against your current compliance obligations and any pending regulatory guidance.
- Insurance Verification: Obtain a certificate of insurance from the third party showing the required cyber liability coverage.
- Operational Readiness: Test your API rate limits, logging infrastructure, and termination procedures before you execute the agreement.
If you're a data provider, build a contract management system that tracks consent expiration dates and renewal cycles. If you're a data recipient, maintain a compliance calendar that flags regulatory comment periods and rule finalization deadlines. The open banking landscape will keep shifting, and your contracts need to shift with it.
