Skip to main content

FAPI-RW-ID2

CONTRACT tier required

FAPI conformance profiles are available on CONTRACT tier accounts only. Contact your account manager to enable them. See plan availability and pricing.

FAPI-RW-ID2 (Financial-Grade API — Part 2, Read/Write, Implementer's Draft 2) is the OpenID Foundation's high-security OAuth 2.0 profile published in 2018. It hardens the standard Authorization Code flow for APIs that move money or expose sensitive financial data, and it underpins several Open Banking ecosystems (including UK Open Banking).

Use this profile if you operate — or consume — a read/write financial API that must demonstrate FAPI-RW conformance to a regulator, partner, or certification body.

How APImetrics checks it

Our implementation of FAPI-RW-ID2 is split into checkpoints, each containing multiple checks that confirm whether a particular observation is compliant. APImetrics classifies each monitored request (token endpoint, authorization endpoint, resource server) and applies the checks relevant to that stage of the flow.

This security profile requires you to include your valid mTLS certificate on all API requests, excluding requests to the authorize endpoint. Some checks are currently unavailable because APImetrics cannot yet correlate different monitors to each other.

Prerequisites

  • A monitor (or workflow) that exercises the full OAuth flow — token endpoint, authorization endpoint, and resource server requests — so each checkpoint has traffic to evaluate.
  • A valid mTLS / signing certificate uploaded for the monitored API. See Certificates.
  • Requests classified correctly by stage; workflows are the easiest way to capture an end-to-end flow.

Enabling the profile

  1. Go to Project Settings → Conformance.
  2. Under Security Profiles, select FAPI-RW-ID2.
  3. Save changes.
  4. Run your monitors (or select Evaluate Most Recent Calls on the Conformance Summary) to generate results.

Interpreting results

Conformance results appear in INVESTIGATE → Conformance. Each row corresponds to a checkpoint below and can be expanded to see the individual checks and the specification section they map to. For triage workflow, see Issue Details.

Checkpoints

Checkpoint 1 — Token Endpoint Call-1 Checks

Looks at the first call to the Authorization Server's Token endpoint — for example, that the body contains the correct parameters and that the TLS version is 1.2 or later.

Checkpoint 2 — OpenBanking Intent ID Checks

Looks at the Account endpoint requests to ensure the correct information is in the request headers and bodies, and that the correct HTTPS code is returned.

Checkpoint 3 — Authorization Request Checks

Looks at the Authorization endpoint requests to ensure the correct information is present in the parameters and that redirects point to a valid URL.

Checkpoint 4 — Authorization Response Checks

Looks at the Authorization endpoint responses to ensure the correct information is present in the headers and payloads.

Checkpoint 5 — Access Token Request Checks

Looks at the Access Token requests to ensure the correct information is present in the parameters.

Checkpoint 6 — Access Token Response Checks

Looks at the Access Token responses to ensure the correct information is present in the parameters.

Checkpoint 7 — Resource Server Checks

Looks at the Resource Server to ensure the correct information is present in the headers.

See also