...
API connections and data in transit must be encrypted using TLS v11.3 2 Mutual Authentication (MA) as a minimum, with a defined set of strong cipher suites.
Transport Layer Security (TLS) v 1.3 2 MA
TLS was designed with the goal of providing privacy and ensuring data integrity between two communicating applications
This has two layers:
The first layer uses TLS Record Protocol to encapsulate other higher level protocols; and
The second layer uses the TLS Handshake Protocol which allows the server and client to authenticate each other. The protocol allows negotiation and agreement of a cryptographic algorithm and keys prior to transmission or receipt of any data.
This is a basic level of security which rides on the TCP protocol and HTTPS. All RESTful APIs by default are created to use this as an encryption mechanism.
In order to achieve full FAPI compliance, all Open Banking stakeholders may run an additional layer of AES 128/256-bit encryption of signatures.
...
Note: The APIs require TLS 1.3 2 Mutual Authentication and this may be used as a means of non-repudiation. However, it would be difficult to maintain digital records and evidence of non-repudiation if the API only relied on TLS 1.32. A solution for non-repudiation that does not rely on TLS, would be achieved by providing a JWS with detached content (as defined in RFC 7515 - Appendix F) in the HTTP header of each API request. The HTTP body would form an un-encoded payload as defined in RFC 7797. The JWS would be signed using an algorithm that supports asymmetric keys. A request would be signed by an AISP’s/PISP’s private key and a response would be signed by the ASPSP's private key. Digital signatures are used to provide non-repudiation and authenticity by using public key algorithms. Private and public key is used to encrypt/decrypt the hash of the content. Encrypted hash is called a digital signature. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. The certificate is digitally signed by the trusted Certificate Authority (CA) – the hash of the certificate is encrypted with the private key of the trusted CA.
...
The API must provide support for out-of-band (OOB) authentication:
Out-of-band (OOB): Out-of-band authentication is a type of authentication that requires a secondary verification method through a separate communication channel along with the typical ID and password. Using a separate authentication channel makes it significantly more difficult for an attacker to intercept and subvert the authentication process;
Forms of OOB authentication include codes sent to a mobile device via SMS, authentication via a voice channel, codes sent to a mobile app via push notifications, and codes sent to or received from a trusted execution environment connected to the host device that is trying to establish an authenticated connection; and
Out-of-band is activity outside a defined telecommunications frequency band, or, metaphorically, outside some other kind of activity "Examples include secure authenticator mobile applications"
ASPSPs must notify the user/customer asynchronously/OOB when significant actions have occurred (e.g. a change to a payee)
The ASPSP API response should inform the third party that an OOB process is underway so that, where appropriate, they can inform the user/customer
ASPSP and AISP/PISP should include fraud-relevant information (e.g. IP addresses, Geo location) in the API messages
The reporting of incidents and the process to handle it shall be covered as per the existing guidelines related to cyber risk in the CBB Rulebook
...