FAPI-RW-ID2
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
- Go to Project Settings → Conformance.
- Under Security Profiles, select FAPI-RW-ID2.
- Save changes.
- 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
- Security profiles overview
- FAPI 2.0 profile
- UK Open Banking conformance
- Conformance guides — set up and interpret conformance monitoring