Third-Party Applications

FAPI 2.0 Security

Data Provider

FAPI 2.0 Security for Third-Party Data Sharing

Standard OAuth 2.0 wasn't designed for financial-grade data sharing. FAPI 2.0 addresses the security gaps with mTLS, signed requests, and token binding—but implementing it from scratch takes 6–12 months of specialized security engineering. Fiskil Data Provider comes pre-certified, so you get FAPI 2.0 security without the implementation burden.

Standard OAuth 2.0 Isn't Enough for Financial Data

Standard OAuth 2.0 lacks the security properties required for financial-grade data sharing. FAPI 2.0 is the answer, but implementing it from scratch requires deep cryptographic expertise and months of engineering effort.

  • mTLS certificate management is operationally complex with rotation, revocation, and chain validation

  • Signed request objects require cryptographic key management infrastructure

  • DPoP (Demonstration of Proof-of-Possession) implementation lacks standard libraries in most ecosystems

  • PAR (Pushed Authorization Requests) adds latency and complexity to authorization flows

  • FAPI conformance testing requires specialized expertise and access to conformance test suites

Pre-Certified FAPI 2.0 Infrastructure

Fiskil Data Provider includes a pre-certified FAPI 2.0 security layer with managed mTLS, request signing, DPoP token binding, and Pushed Authorization Requests. No custom cryptographic implementation required.

Capabilities

Key Capabilities

Managed mTLS

Full mutual TLS certificate lifecycle management including issuance, rotation, revocation, and chain validation. Certificates are provisioned automatically for registered partners and rotated on configurable schedules without service interruption.

Request Object Signing

Automatic signing and verification of OAuth request objects using your choice of RS256, PS256, or ES256 algorithms. Key management is handled by Fiskil, including rotation, backup, and hardware security module integration where required.

DPoP Token Binding

DPoP (Demonstration of Proof-of-Possession) implementation that binds access tokens to the requesting client's cryptographic key. Prevents token theft and replay attacks, which is required by FAPI 2.0 for financial-grade security.

Pushed Authorization Requests (PAR)

PAR endpoint that accepts authorization requests as authenticated POST requests instead of URL query parameters. Eliminates request parameter leakage, supports large request payloads, and provides request object integrity validation.

Implementation

Implementation Guide

Enabling FAPI 2.0 security on Fiskil Data Provider typically takes 1–2 weeks, primarily for certificate configuration and conformance testing.

1

Enable FAPI Profile

Activate the FAPI 2.0 security profile on your Fiskil Data Provider instance. This enables all FAPI-required security features: mTLS, signed request objects, DPoP, and PAR. Non-FAPI endpoints continue to work normally during the transition.

2

Configure mTLS Certificates

Set up the mTLS certificate authority. Choose between Fiskil-managed CA, your own enterprise CA, or a third-party CA. Configure certificate policies including validity period, key size requirements, and revocation check mechanisms.

3

Set Up PAR Endpoint

Configure the Pushed Authorization Request endpoint. Set request lifetime, maximum request size, and supported grant types. Test the PAR flow with your registered applications to verify correct operation.

4

Verify with Conformance Suite

Run the FAPI 2.0 conformance test suite against your configured endpoints. Fiskil provides a built-in conformance runner that tests all FAPI 2.0 requirements and generates a certification report. Address any failures before enabling production traffic.

Features

Key Features

Certificate Lifecycle Management

Automated certificate issuance, renewal, and revocation for all mTLS connections. Supports OCSP stapling and CRL distribution for real-time revocation checking.

Request Signing Service

Centralized request signing service that handles key management, algorithm selection, and signature verification. Supports RS256, PS256, and ES256 signing algorithms.

Token Binding Enforcement

Automatic enforcement of DPoP token binding on all data access requests. Tokens without valid proof-of-possession are rejected, preventing token theft and replay attacks.

PAR Server

High-availability PAR server that accepts authenticated authorization requests. Supports request object encryption, lifetime management, and one-time-use enforcement.

Conformance Test Suite

Built-in FAPI 2.0 conformance test runner that validates your configuration against the full FAPI 2.0 specification. Generate certification-ready reports with one command.

Security Event Monitoring

Real-time monitoring of security events including certificate failures, signature verification errors, DPoP violations, and suspicious access patterns. Integrates with your existing SIEM.

"Partnering with Fiskil on our open data needs has been a game-changer for us in delivering and maintaining our data holder solution."

Fiskil logo

Fahad Liaqat at Pacific Blue

Executive Manager Operations and New Markets

FAQs

FAPI 2.0 is a significant security upgrade. Key changes: FAPI 2.0 requires DPoP or mTLS token binding (FAPI 1.0 allowed bearer tokens); FAPI 2.0 mandates PAR (FAPI 1.0 allowed query parameter authorization requests); FAPI 2.0 simplifies the profile structure from Advanced/Baseline to a single security profile. Fiskil implements FAPI 2.0.

With Fiskil, the technical implementation takes 1–2 weeks. Running the conformance test suite and generating the certification report takes another 2–3 days. The total timeline from decision to certification is typically 3–4 weeks, compared to 6–12 months for custom implementations.

Fiskil handles mTLS complexity entirely. Certificate issuance, rotation, revocation, and chain validation are automated. You configure the policy (validity period, key size, rotation schedule) and Fiskil manages the operational details. Partners receive certificates through the onboarding portal.

FAPI 2.0 adds approximately 20–40ms of latency to each request for mTLS handshake, DPoP verification, and request object validation. The PAR flow adds one additional round trip (typically 50–100ms) but this occurs only during initial authorization, not on every data request.

FAPI 2.0 is not directly backward compatible, but Fiskil supports running both profiles simultaneously during migration. Existing FAPI 1.0 clients continue to work while new clients onboard on FAPI 2.0. You can set a migration deadline after which FAPI 1.0 is deprecated.

Australia's CDR mandates FAPI 2.0 for all data holders and recipients. Brazil's Open Finance requires FAPI. The UK's Open Banking uses a FAPI-based security profile. The US Section 1033 references FAPI security standards. PSD3 in Europe is expected to adopt FAPI 2.0. Even without a mandate, FAPI is considered best practice for financial data sharing.

Yes. Fiskil supports three CA options: Fiskil-managed CA (simplest), your enterprise CA (most control), or a third-party CA like DigiCert or Let's Encrypt (for compatibility with existing PKI). The CA choice doesn't affect FAPI compliance—all options meet the specification requirements.

DPoP keys are generated and managed by the client application (not by Fiskil). Each client generates an asymmetric key pair and includes a proof-of-possession JWT with every token request. Fiskil verifies the proof against the client's public key. This design means clients control their own keys without sharing private key material.

Get started today

Talk to us about what you're building and we'll show you how we can help.

Loading Contact Form...
Fiskil logo

© Fiskil 2026. All rights reserved.

FAPI 2.0 Security for Third-Party Data Sharing | Fiskil...