What is Financial-Grade Security?

What is Financial-Grade Security?

On this page


Financial-grade or 'bank-grade' security focuses on meeting current industry requirements related to data protection. To be compliant and interoperable, companies in some sectors need to meet financial regulations:

  • Directive on Payment Services (PSD2)
  • Open Banking Implementation (OBIE) in the UK

Keeping user data private is another important regulatory requirement, which has a number of variations in different global locations:

  • Europe's General Data Protection Regulation (GDPR)
  • Australian Privacy Principles (APP)
  • Brazil's LGPD
  • South Korea's PIPA

An improved security model is also very relevant for protecting high-worth data outside of the financial world. In this article, we'll drill into the main financial-grade security concerns and describe the best practices for dealing with them.

Modern Security Standards

OAuth and OpenID Connect are international standards that provide a framework for securing APIs. OAuth is commonly used for interoperability between companies, and can be integrated into any type of client application, including web and mobile.

FAPI Working Group

The Financial-grade API (FAPI) Working Group provides guidance on constraining the OAuth framework into a number of 'profiles' suited to the financial sector to help meet a particular set of regulatory requirements.

The below example documents illustrate how banking-grade applications need to go beyond normal application security to apply extra protection for sensitive data:

Support for Evolving OAuth Standards

Some areas of the above documents are already mainstream and widely supported, whereas others are not. It is vital that your Authorization Server keeps up to date with security standards to implement financial profiles.

OAuth Threats

In this article, we will focus on threats in the following areas, where best practices have evolved in the last year or two:

Stolen IdentityThe risk of an attacker signing in using a genuine user's credentials
Stolen OAuth TokensThe risk of a stolen token used by a malicious party to access data
Browser VulnerabilitiesThe risk of malware exploiting potential weakness during authentication redirects


The above threats need to be managed across all components, so we will provide some financial-grade recommendations on securing APIs and various types of clients:

Threat management across components, APIs and clients

Strong Customer Authentication (SCA)

One of the main actions to solve the stolen identity problem is to use Multi-Factor Authentication (MFA). MFA uses at least two of these areas:

  • Something the user knows (like a password)
  • Something the user has (like a phone or key fob)
  • Something the user is (like their voiceprint or fingerprint)

With financial API transactions, the data is usually very valuable. Therefore, FAPI guidelines indicate that users should sign in to apps with MFA, to provide a high Level of Assurance (LoA).

Authentication Policies

Authentication can be more complex than just a user providing credentials. There are advantages to implementing an authentication policy that can react to contextual information:

  • The user's current location may influence how they log in or whether it should be allowed.
  • A large number of prior login attempts may indicate a security threat.
  • The authentication policy may need hardening when there is an active threat.

Curity Identity Server Authentication

The Curity Identity Server manages strong authentication in an extensible manner, where you can implement as many factors as you'd like, as a workflow, with rules based on runtime context.

Pairwise Pseudonymous Identifiers (PPIDs)

A financial-grade solution should aim to limit its use of personal user information. It's a good practice for the app (or a group of related apps) to receive only a generated identifier for the user and store any application-specific data against that ID.

Pairing of user IDs per sector

More sensitive values such as name and email can be stored in the Authorization Server, where they are audited and returned to the application in tokens. See the page on Pairwise Pseudonymous Identifiers for further details.

Sender-Constrained Tokens

OAuth access tokens are typically bearer tokens, and if one is stolen somehow, it can be successfully sent to your APIs by a malicious client.

To prevent this, we need to ensure that the API client is the one for whom the token was issued. We do so by demonstrating 'proof of possession' using an additional public and private key pair:

  • Proof of private key ownership is used when the client authenticates with the authorization server.
  • The authorization server then issues a hash of the public key in access tokens as a different claim.
  • Proof of private key ownership is sent whenever the client calls the API.
  • The API verifies every request's proof of ownership and ensures that the public key matches the claim in the access token.

Public Clients and DPoP

This design pattern ensures that if an access token is ever stolen, the malicious client will not have the private key and will receive an access denied response if they attempt to send the token to your API.

Confidential Client Implementation

The most straightforward implementation of sender-constrained tokens is to use Mutual TLS and X509 client certificates, via Certificate-Bound Access Tokens, as described in RFC8705.

This is used for confidential client scenarios, such as API calls between companies, and relies on a Public Key Infrastructure (PKI), which most financial companies already have. In the below diagram, tokens are sent through a Mutual TLS tunnel:

Confidential Clients and Mutual TLS

The access token claim, in this case, includes a confirmation claim containing the certificate thumbprint at the time of authentication:

    "cnf": {
        "x5t#S256": "FjeHcvJwiHXlr8dgnP7UvLQ7dLLMTe_3SgMYMuEpekc"

When APIs validate tokens, they also verify that this claim corresponds to the Mutual TLS tunnel's public key. An attacker who steals a token will not have access to this client key.

This flow can be implemented quite easily with standard OAuth and HTTP libraries, since client certificate technology has been used between companies for many years. See the Mutual TLS Sender-Constrained Access Tokens article for further details.

Public Client Implementation

It is not practical for web and mobile clients to use client certificates, so they implement sender-constrained tokens differently. A technique called Demonstrable Proof of Possession (DPoP) is used, as described in the DPoP draft standard.

The client first generates a private and public key using WebCrypto technology encoded into a Json Web Key. Proof of possession is then provided by client-side code, which creates a signed JWT and includes the JWK public key in its header. The JWT is then sent in HTTP requests via a DPoP HTTP header.

Public Clients and DPoP

During authentication, the Authorization Server verifies the DPoP details and then writes an extra confirmation claim to access tokens it issues, containing the JWK's public key thumbprint.

    "cnf": {

A DPoP JWT also provides claims to specify the HTTP endpoint and method that it is valid for. The DPoP JWT is a short-lived value, and a new value is sent on every API call, along with the access token, which is now a 'DPoP token' and no longer a 'bearer token':

GET /resource HTTP/1.1
Host: api.example.com
Authorization: DPoP eyJhbGci...hF1MQ
DPoP: eyJ0eXAi...4UCbQ

Implementing this flow is currently quite challenging, since standard OAuth libraries do not yet support DPoP, and you will need to write more security code than usual.

API Gateway Role

A Reverse Proxy or API Gateway is another essential part of your financial-grade solution. A key behavior we recommend is the Phantom Token Pattern, which ensures that access tokens exposed to the outside world are minimal and confidential, with the real security state stored in the Authorization Server.

The Authorization Server will support multiple routes for authentication, and one of them will terminate Mutual TLS to verify the client certificate for confidential clients:

API Gateway:Termination of Mutual TLS to verify the client certificate

Mutual TLS (if used) is terminated at the entry point to use the phantom token pattern. The reverse proxy verifies proof of possession for either Mutual TLS or DPoP clients, then forwards the public key to APIs.

API Gateway: Reverse proxy forwards the public key to APIs

APIs can also securely call each other 'inside the cluster' when required, and on every API request, the access token's scopes and claims will be verified. For financial-grade security, this includes verifying the 'cnf' claim against the received public key.

Browser Vulnerabilities

Public clients traditionally use the system browser to manage logins, which is a less trusted environment than the direct HTTPS connections used to call APIs. During redirects, there are many attack vectors that OAuth protects against.

One of these risks is a Man in the Browser (MITB) attack, where malware can potentially intercept and tamper with OAuth request and response messages. This risk is addressed by the below specifications, which are expected to become mainstream for financial-grade security:

These standards provide message-level security via additional JWTs, in a similar manner to DPoP. The article on Signed Request Objects covers this topic in further depth.

Mobile Authentication Risks

When developing OAuth mobile apps, there are risks that malicious apps could potentially intercept a login response or use the app's client ID to impersonate the genuine app.

Dealing with these risks requires some additional actions, as described in the OAuth for Mobile Apps Best Practices article, which recommends the following mitigations:

Public Clients and Attestation

One of the weaknesses in traditional OAuth is that public clients are not authenticated before user authentication begins, meaning a malicious app can attempt to authenticate as a public client.

It is possible to improve security by making additional checks against the client application before allowing an authentication attempt. See the below links for further details:

Implementing Financial-Grade

Financial-grade security requires implementations across several different components:

  • An Authorization Server that supports all of the above standards
  • An API Gateway that implements the phantom token pattern
  • A Public Key Infrastructure (PKI) for connections from confidential and attested public clients
  • Web and mobile apps must implement up to date flows in a best practice manner

Standard (non-financial-grade) OAuth flows are well-supported by OAuth libraries, but newer features such as DPoP, JAR, and JARM are not.

HAAPI and Public Clients

To make banking-grade implementations of web and mobile apps more seamlessly integrated, Curity provides a Hypermedia API Authentication (HAAPI) solution, which deals with all of the following concerns:

  • Sender-constrained DPoP tokens are used for web and mobile apps to prevent stolen token risks.
  • Client attestation is used to verify the public client's identity before authentication.
  • Authentication is implemented as a workflow that easily supports multiple factors.
  • The authentication policy can be dynamically updated without redeploying apps.
  • Login does not usually need to leave the app, for an improved user experience.
  • Integration is technically simple via SDKs, requiring only a moderate amount of code.


The Curity Identity Server has extensive support for the standards mentioned in this article. We continually improve our financial-grade capabilities for all types of OAuth clients and aim to be financial-grade by default.

For further details on the security topics in this article, see our Financial-Grade APIs Whitepaper.