Tyk FAPI Accelerator for Open Banking
Last updated:
Introduction
Open Banking is a financial services framework that enables secure data sharing between banks and third-party providers (TPPs) through standardized APIs. It fosters innovation, enhances customer experiences, and ensures compliance with regulatory requirements such as:
- Payment Services Directive 2 (PSD2) (PSD2) in the European Union, mandating secure access to account information and payment services.
- UK Open Banking (UK Open Banking), a UK initiative for standardized financial APIs.
- Consumer Data Right (CDR) (CDR) in Australia, enabling consumer data sharing.
- Financial Data Exchange (FDX) (FDX) in the United States, an industry-led standard for data sharing.
Open Banking is enabling the banking industry to move from closed ecosystems to open standards and collaborative platforms where customer data can be securely shared with authorized third parties. However, financial institutions face challenges implementing secure, compliant, Open Banking APIs. This document explores how Tyk API Gateway, through its FAPI Accelerator, enables financial institutions to implement robust Open Banking APIs.
Challenges in Financial Services API Implementation
Implementing Open Banking APIs presents several challenges:
-
Stringent Security Requirements:
- Compliance with Financial-grade API (FAPI) standards, such as FAPI 2.0, which ensure high-security API interactions.
- Ensuring data integrity, authenticity, and non-repudiation for sensitive financial transactions.
-
Complex Authentication:
-
Event Notifications:
- Enabling TPPs to subscribe to real-time updates about account and payment events.
- Signing notifications with cryptographic signatures for security.
-
Idempotency:
- Ensuring that duplicate requests (especially for payments) don’t result in duplicate transactions.
-
Developer Experience:
- Providing a seamless experience for TPP developers while maintaining high-security standards.
What is Tyk FAPI Accelerator?
The Tyk FAPI Accelerator is a reference implementation provided by Tyk Technologies to help financial institutions build secure, standards-compliant Open Banking APIs. Built on the Tyk API Gateway.
Architecture Overview
The diagram below shows the Tyk FAPI Accelerator system in its environment, including users, external systems, and key actors.
flowchart TB
%% People/Actors
psu(["PSU (Payment Services User)
A customer of the bank who accesses their accounts and initiates payments through third-party providers"])
tpp(["TPP (Third Party Provider)
Companies providing financial services like account aggregators, credit checkers, and savings apps that integrate with banks"])
aspsp(["ASPSP (Account Servicing Payment Service Provider)
Banks and financial institutions that provide account and payment APIs to authorized third parties"])
%% Systems
subgraph tykFAPI ["Tyk FAPI Accelerator"]
tykFAPISystem["Provides FAPI-compliant APIs for account information and payment initiation"]
end
%% Relationships
psu -->|"Views accounts,
initiates payments"| tykFAPI
tpp -->|"Integrates with,
consumes APIs from"| tykFAPI
aspsp -->|"Configures, monitors,
provides services through"| tykFAPI
%% Styling
classDef person fill:#335FFD,color:#F7F7FF,stroke:#9393AA
classDef system fill:#00A3A0,color:#F7F7FF,stroke:#03031C
class psu,tpp,aspsp person
class tykFAPISystem system
Tyk FAPI Accelerator
The diagram below shows all major components of the Tyk FAPI Accelerator and their interactions.
flowchart TB
%% People/Actors
psu(["PSU (Payment Services User)
A customer of the bank who accesses their accounts and initiates payments through third-party providers"])
tpp(["TPP (Third Party Provider)
Companies providing financial services like account aggregators, credit checkers, and savings apps that integrate with banks"])
%% Tyk FAPI Accelerator System with Containers
subgraph tykFAPI ["Tyk FAPI Accelerator"]
tppApp["TPP Application
(NextJS)
Demonstrates how a TPP would interact with a bank's API"]
apiGateway["API Gateway
(Tyk Gateway)
Secures and routes API requests, enforces FAPI compliance, and handles event notifications"]
authServer["Authorization Server
(Keycloak)
Handles authentication and authorization"]
tykBank["Tyk Bank
(Node.js)
Mock bank implementation providing backend services"]
database[(Database)]
databaseLabel["PostgreSQL
Stores account information, payment data, and event subscriptions"]
kafka[(Message Broker)]
kafkaLabel["Kafka
Handles event notifications"]
end
%% Connect labels to database and kafka
database --- databaseLabel
kafka --- kafkaLabel
%% Relationships
psu -->|"Uses
(HTTPS)"| tppApp
tpp -->|"Develops
(IDE)"| tppApp
tppApp -->|"Makes API calls to
(HTTPS)"| apiGateway
tppApp -->|"Authenticates with
(OAuth 2.0/OIDC)"| authServer
apiGateway -->|"Routes requests to
(HTTPS)"| tykBank
authServer -->|"Verifies consents with
(HTTPS)"| tykBank
tykBank -->|"Reads from and writes to
(SQL)"| database
tykBank -->|"Publishes events to
(Kafka Protocol)"| kafka
%% Event notification flow
kafka -->|"Subscribes to events"| apiGateway
apiGateway -->|"Sends signed notifications
(JWS/HTTPS Webhooks)"| tppApp
%% Styling
classDef person fill:#335FFD,color:#F7F7FF,stroke:#9393AA
classDef tppStyle fill:#335FFD,color:#F7F7FF,stroke:#9393AA
classDef component fill:#00A3A0,color:#F7F7FF,stroke:#03031C
classDef authStyle fill:#00A3A0,color:#F7F7FF,stroke:#03031C
classDef bankStyle fill:#C01FB8,color:#F7F7FF,stroke:#03031C
classDef kafkaStyle fill:#E09D00,color:#F7F7FF,stroke:#03031C
classDef database fill:#5900CB,color:#F7F7FF,stroke:#03031C
classDef label fill:none,stroke:none
class psu,tpp person
class tppApp tppStyle
class apiGateway component
class authServer authStyle
class tykBank bankStyle
class database database
class kafka kafkaStyle
class databaseLabel,kafkaLabel label
Key Components
-
API Gateway (Tyk Gateway):
- Routes API requests to appropriate backend services
- Implements DPoP authentication via gRPC plugin
- Handles idempotency for payment requests
- Signs and delivers event notifications to TPPs
-
Authorization Server (Keycloak):
- Provides FAPI 2.0 compliant OAuth 2.0 and OpenID Connect
- Supports Pushed Authorization Requests (PAR)
- Manages user authentication and consent
-
Mock Bank Implementation:
- Implements UK Open Banking Account Information API
- Implements UK Open Banking Payment Initiation API
- Implements UK Open Banking Event Subscriptions API
- Provides realistic testing environment
-
TPP Application:
- Demonstrates how third parties integrate with the bank’s APIs
- Implements FAPI 2.0 security profile
- Shows account information retrieval and payment initiation flows
Security Features
The Tyk FAPI Accelerator implements several security features required for financial-grade APIs:
-
DPoP (Demonstrating Proof of Possession):
- Ensures the client possesses the private key corresponding to the public key in the token
- Prevents token theft and replay attacks
- Implemented as a gRPC plugin for Tyk Gateway
-
JWS Signing for Event Notifications:
- Signs webhook notifications with JSON Web Signatures (JWS)
- Ensures authenticity and integrity of notifications
- Allows TPPs to verify the source of notifications
-
Idempotency Support:
- Prevents duplicate transactions from repeated API calls
- Caches responses for idempotent requests
- Includes automatic garbage collection of expired entries
-
OAuth 2.0 with PAR:
- Implements Pushed Authorization Requests for enhanced security
- Supports both automatic and manual authorization flows
- Complies with FAPI 2.0 security profile
Getting Started
For detailed setup instructions, code examples, and deployment guides, please refer to the Tyk FAPI Accelerator GitHub repository.
Implementation Examples
Payment Flow Example
The following sequence diagram illustrates a typical payment flow in the Tyk FAPI Accelerator:
sequenceDiagram
actor User as End User
participant TPP as TPP Application
participant Gateway as API Gateway
participant Auth as Authorization Server
participant Bank as Tyk Bank
participant DB as Database
participant Kafka as Message Broker
%% Payment Initiation
User->>TPP: 1. Initiate payment (amount, recipient)
%% Payment Consent Creation
TPP->>Gateway: 2. Create payment consent
Gateway->>Bank: 3. Forward consent request
Bank->>DB: 4. Store consent
DB-->>Bank: 5. Return consent ID
Bank-->>Gateway: 6. Consent response with ConsentId
Gateway-->>TPP: 7. Return ConsentId
%% Pushed Authorization Request (PAR)
TPP->>Auth: 8. Push Authorization Request (PAR)
Note right of TPP: Direct connection to Auth Server
Auth-->>TPP: 9. Return request_uri
%% Authorization Options
TPP->>User: 10. Display authorization options
%% Two possible authorization flows
alt Automatic Authorization
User->>TPP: 11a. Select automatic authorization
TPP->>Bank: 12a. Direct authorize consent request
Note right of TPP: Server-side authorization
Bank->>DB: 13a. Update consent status
DB-->>Bank: 14a. Confirm update
Bank-->>TPP: 15a. Authorization confirmation
else Manual Authorization
User->>TPP: 11b. Select manual authorization
TPP->>User: 12b. Redirect to authorization URL
User->>Auth: 13b. Authorization request with request_uri
Auth->>Bank: 14b. Verify consent
Bank->>DB: 15b. Get consent details
DB-->>Bank: 16b. Return consent details
Bank-->>Auth: 17b. Consent details
Auth->>User: 18b. Display authorization UI
User->>Auth: 19b. Approve authorization
Auth->>DB: 20b. Update consent status
DB-->>Auth: 21b. Confirm update
Auth->>User: 22b. Redirect to callback URL with code
User->>TPP: 23b. Callback with authorization code
end
%% Payment Creation
TPP->>Gateway: 24. Create payment with authorized consent
Gateway->>Bank: 25. Forward payment request
Bank->>DB: 26. Store payment
DB-->>Bank: 27. Return payment ID
Bank-->>Gateway: 28. Payment response with PaymentId
Gateway-->>TPP: 29. Return PaymentId
%% Payment Confirmation
TPP->>User: 30. Display payment confirmation
%% Event Notification
Bank->>Kafka: 31. Publish payment event
Kafka->>Bank: 32. Stream processor consumes event
Bank->>DB: 33. Query subscriptions
DB-->>Bank: 34. Return matching subscriptions
Bank->>TPP: 35. Send payment notification
TPP-->>Bank: 36. Acknowledge notification
Event Notification Example
The event notification system allows TPPs to receive updates about payment status changes:
sequenceDiagram
actor TPP as TPP Application
participant Gateway as API Gateway
participant EventAPI as Event Subscriptions API
participant PaymentAPI as Payment Initiation API
participant DB as Database
participant Kafka as Message Broker
%% Subscription Registration
TPP->>Gateway: 1. Register callback URL
Gateway->>EventAPI: 2. Forward registration request
EventAPI->>DB: 3. Store subscription
DB-->>EventAPI: 4. Return subscription ID
EventAPI-->>Gateway: 5. Registration response with SubscriptionId
Gateway-->>TPP: 6. Return SubscriptionId
%% Event Generation
Note over PaymentAPI: Payment status change or other event occurs
PaymentAPI->>Kafka: 7. Publish event
Note right of PaymentAPI: Event includes type, subject, timestamp
%% Event Processing
Kafka-->>Gateway: 8. Consume event
Gateway->>DB: 9. Query subscriptions for event type
DB-->>Gateway: 10. Return matching subscriptions
Gateway->>Gateway: 11. Determine target TPPs and sign with JWS
%% Notification Delivery
Gateway->>TPP: 12. Send signed notification
Note right of Gateway: Notification includes event details, links, and JWS signature
TPP->>TPP: 13. Verify JWS signature
TPP-->>Gateway: 14. Acknowledge (HTTP 200 OK)
%% Error Handling (Alternative Flow)
alt Delivery Failure
Gateway->>TPP: 12. Send signed notification
TPP--xGateway: 13. Failed delivery (timeout/error)
Gateway->>Gateway: 14. Retry with exponential backoff
Gateway->>TPP: 15. Retry notification
TPP->>TPP: 16. Verify JWS signature
TPP-->>Gateway: 17. Acknowledge (HTTP 200 OK)
end