---
name: prompt-pack-open-banking-api-terms
description: Use when drafting API terms of service for a bank or fintech offering open banking APIs to third-party providers (TPPs), developers, or payment initiation services. Covers access credentials, rate limits, data usage restrictions, security requirements, liability, SLA commitments, and compliance with applicable open banking regulations. MENA-focused: UAE Central Bank open finance framework, SAMA open banking framework (KSA), and EU PSD2 as a reference standard.
license: MIT
metadata:
  id: prompt-pack.open-banking-api-terms
  category: prompt-pack
  practice_area: fintech-payments
  priority: P2
  intent: [drafting, open-banking-api-terms]
  related:
    - prompt-pack-lending-platform-terms
    - prompt-pack-payment-services-agreement
    - prompt-pack-payment-facilitator-agreement
    - prompt-pack-privacy-impact-assessment
    - heuristic-always-state-jurisdiction-first
  source: Louis — HAQQ Legal AI (github.com/sboghossian/mini-claude-for-legal)
  version: "1.0"
---

# Open Banking API Terms

## When to use this

Use this skill when a bank, financial institution, or fintech company needs to draft the API terms of service governing third-party access to its open banking APIs. The document is addressed to third-party providers (TPPs) — developers, payment initiation service providers (PISPs), account information service providers (AISPs), or other authorized partners.

Triggers:
- "Draft API terms for our open banking platform."
- "We need terms of service for third-party developers accessing our banking APIs."
- "Draft a developer agreement for our open finance sandbox."

## Required inputs

| Input | Why it matters | Default |
|---|---|---|
| API Provider (bank/fintech) name | Identifies the issuing institution | Ask user |
| Jurisdiction / regulatory framework | Determines compliance obligations (SAMA, UAE CBUAE, PSD2, etc.) | Ask user |
| API types offered | Account information, payment initiation, card issuance — different regulatory treatments | Ask user |
| TPP eligibility requirements | Who may apply — licensed entities only vs open to all developers | Ask user |
| Commercial model | Free / freemium / paid API access — determines billing terms | Ask user |

## Optional inputs

- Sandbox vs production environment distinction
- Whether OAuth 2.0 / OpenID Connect is the authentication standard
- Rate limiting parameters (calls per second, daily limits)
- Insurance requirements for TPPs (cyber liability, professional indemnity)
- Data residency requirements

## Document structure

### 1. Introduction and Acceptance
- Provider identity and regulatory status
- What these terms govern: the right to access and use [Provider's] APIs
- How acceptance occurs: registering for developer access, or executing a separate API licence agreement for production access
- Who may accept: only eligible entities (see eligibility section)

### 2. Eligibility and Registration

**Eligibility**:
- TPPs must be licensed or authorized under applicable law to provide the relevant services (AISP, PISP, fintech licence)
- In KSA: authorization from SAMA's Open Banking Lab required
- In UAE: compliance with UAE Central Bank Open Finance regulation
- In EU: PSD2-compliant authorization from home-country competent authority (or exemption)

**Registration process**:
- Create a developer account at [Developer Portal URL]
- Submit required documents: company registration, regulatory licence, data protection policy, cyber security questionnaire
- Agree to these API Terms
- Provider reviews and approves; issues API credentials (client ID, client secret) upon approval
- Separate production access approval required after successful sandbox testing

### 3. API Access and Credentials

**Access grant**:
> "Subject to these Terms, Provider grants TPP a limited, non-exclusive, non-transferable, revocable licence to access and use the APIs solely for [building licensed TPP services for Provider's customers / developing and testing applications in the sandbox environment]."

**Credential obligations**:
- TPP must keep API credentials (client ID, client secret, certificates) secure and confidential
- Credentials must not be shared with sub-contractors or embedded in client-facing code
- Immediate notification to Provider if credentials are compromised
- Each application or service must use separate API credentials (no credential sharing across products)

**No data scraping**: APIs must not be used to scrape, index, or aggregate data beyond the permitted scope; screen-scraping of Provider's interfaces is prohibited even if technically possible.

### 4. Permitted and Prohibited Uses

**Permitted uses**:
- Account information services (AIS): accessing account balance, transaction history with customer consent
- Payment initiation services (PIS): initiating payments from customer accounts with customer consent
- Card-based payment instrument issuance (CBPII): confirming availability of funds for card transactions with consent
- Application development and testing in the sandbox environment

**Prohibited uses**:
- Using API data for purposes not authorized by the customer's consent
- Selling, sublicensing, or sharing API data with third parties without express customer and Provider authorization
- Using APIs in applications that facilitate illegal activity, money laundering, or terrorist financing
- Automated bulk data collection or harvesting
- Reverse engineering the APIs or Provider's systems
- Any use that would violate applicable data protection law

### 5. Rate Limits and Technical Standards

- API rate limits: [X] calls per second per TPP; [Y] calls per day per customer; [Z] calls per month in total
- Exceeding rate limits: requests above the limit will receive a 429 (Too Many Requests) response; sustained excess may result in suspension
- Authentication: OAuth 2.0 with PKCE; OpenID Connect for identity; FAPI (Financial-grade API) profile mandatory for production access
- Transport security: TLS 1.2 minimum; TLS 1.3 preferred
- API versioning: Provider will maintain APIs for [12 months] after a new version is released; advance notice of [90 days] for breaking changes

### 6. Data Protection and Privacy

- TPP must have a compliant privacy policy and data processing agreement in place with each end customer before accessing their data via the APIs
- Customer consent must be obtained in the form required by applicable law (PSD2 explicit consent; UAE CBUAE consent framework; SAMA consent framework)
- TPP must not process customer data for any purpose beyond what is authorized by the customer's consent
- Data retention: TPP must delete customer API data within [90 days] of consent withdrawal or customer request
- **Data processing agreement (DPA)**: a DPA between Provider and TPP is required for production access where Provider acts as data processor on behalf of TPP (or vice versa, depending on data flows) — attach as Annex [X]

### 7. Security Requirements

TPP must implement and maintain:
- ISO 27001 or equivalent information security management
- Annual penetration testing with reports available to Provider on request
- Vulnerability disclosure program
- Encryption of all customer data at rest (AES-256) and in transit (TLS 1.3)
- Multi-factor authentication for all access to API management systems
- Incident response plan covering API-related security incidents
- Notification to Provider of any security incident involving API access within [24 hours] of discovery

### 8. Service Level Agreement (Provider's Obligations)

| Metric | Target |
|---|---|
| API availability (production) | ≥ 99.5% per calendar month |
| API availability (sandbox) | Best efforts |
| Scheduled maintenance notice | ≥ 72 hours advance notice |
| Critical security patch deployment | Within [24 hours] of known exploit |
| API response time (95th percentile) | ≤ [500 ms] for account information endpoints |
| Support response time (critical issues) | ≤ [4 hours] during business hours |

Service credits for SLA breaches: [state credit mechanism or say "not applicable"].

### 9. Liability

**Provider's limitation of liability**:
- Provider is not liable for: failure of TPP's applications; customer losses arising from TPP's use of APIs; incorrect or incomplete API data arising from errors in customer records
- Provider's total liability to TPP in any 12-month period is limited to [EUR 500,000 / USD 500,000 / or fees paid in the period, whichever is lower]

**TPP's indemnity**:
- TPP indemnifies Provider against claims arising from: TPP's breach of these Terms; TPP's unauthorized use of customer data; TPP's non-compliance with applicable regulatory requirements

**Carve-outs from Provider's limitation**: fraud, gross negligence, willful misconduct, data protection breach (subject to applicable regulatory maximum).

### 10. Compliance Obligations

TPP represents and warrants on a continuing basis:
- It holds all required licences and authorizations to provide the services it offers using the APIs
- It complies with applicable AML/CFT law (FATF 40 Recommendations; UAE AML Cabinet Decision; KSA AML Law; EU AMLD)
- It complies with applicable data protection law (GDPR, UAE PDPL, KSA PDPL)
- Its use of the APIs does not violate applicable payment systems rules (Mastercard, Visa, local payment network rules)
- It has a documented information security policy reviewed at least annually

### 11. Certification and Audit

- Provider may require TPP to provide third-party audit reports (SOC 2, ISO 27001 certificate) annually
- Provider has the right to audit TPP's API usage logs on [30-day] notice to verify compliance
- Provider may conduct technical testing of TPP's API integration to verify security compliance

### 12. Term and Termination

- These Terms remain in effect for as long as TPP has active API credentials
- Provider may suspend or terminate API access immediately for: breach of security requirements; regulatory compliance failure; unauthorized data use; Provider required to do so by its regulator
- TPP may terminate by written notice and deregistering its applications
- Upon termination: TPP must delete all API data and certify deletion; outstanding API calls will be rejected

### 13. Governing Law and Regulatory Compliance
- MENA-jurisdiction APIs: governing law should match Provider's regulator (UAE CBUAE → UAE law; SAMA → KSA law)
- Cross-border APIs: consider DIFC or ADGM as neutral forum for international TPPs
- Nothing in these Terms limits the authority of any competent regulator

## Jurisdictional notes

| Jurisdiction | Framework |
|---|---|
| **UAE** | UAE Central Bank Open Finance Regulation (2023); phased rollout; banks required to offer open banking APIs in prescribed formats; TPPs require CBUAE licence. |
| **KSA** | SAMA Open Banking Framework (2022); Open Banking Lab for TPP onboarding; Fintech Saudi support; API standards aligned with Berlin Group NextGenPSD2 framework. |
| **EU (PSD2)** | Strong Customer Authentication (SCA) mandatory; banks must offer dedicated API interface; XS2A (Access to Accounts) rights for licensed TPPs; RTS on SCA sets technical standards. |
| **UK (post-Brexit)** | Open Banking Implementation Entity (OBIE) standards; CMA9 banks must offer open banking APIs; FCA authorizes AISPs and PISPs. |

## Common mistakes

- **Not requiring TPP regulatory licence verification at onboarding**: allowing any developer to access production APIs without verifying licence status exposes Provider to regulatory and reputational risk.
- **No rate limiting**: without rate limits, a single TPP can overload the API and cause service degradation for all other TPPs and customers.
- **Weak data deletion obligation**: MENA data protection laws require specific deletion timelines; vague retention language creates compliance risk.
- **No DPA**: where the API involves processing of personal data on behalf of customers, a formal DPA between Provider and TPP is legally required under GDPR, UAE PDPL, and KSA PDPL.

## Related skills

- [[prompt-pack-lending-platform-terms]]
- [[prompt-pack-payment-services-agreement]]
- [[prompt-pack-payment-facilitator-agreement]]
- [[prompt-pack-privacy-impact-assessment]]
- [[heuristic-always-state-jurisdiction-first]]