1. Introduction

This page lists planned future functionality not yet included in this version of the Standards. Once the details of this functionality have been confirmed by Nebras, this will be included in a future version of the Standards.

2. Planned Functionality

2.1 Product Data Lending Rates Encryption/Decryption

2.1.2 Overview

Following consultations with the ecosystem, a key requirement has emerged: ensuring that end users can view and understand all charges, fees, interest charged on their financial credit based products (e.g., loans, mortgages, credit cards) through a TPP using Open Finance APIs — without granting the TPP access to the interest / profit rate charged data.

We have translated this context into the following requirement:

Make architectural changes to the Open Finance APIs so that the LendingRates returned from the GET /accounts/{AccountId}/product endpoint for credit cards, loans, and mortgages can be displayed within a TPP’s customer-facing interface, without the charges and lending rates ever reaching or being stored on the TPP’s servers.

As part of Nebras' commitment to delivering Open Finance in a way that meet the needs of all participants, we are implementing within the standards and the API Hub support for this requirement.

2.1.2 Approach

1. When a GET /accounts/{AccountId}/product request is made for credit card, loan, or mortgage products, the LFI encrypts LendingRates before transmission to the API Hub and then to the TPP (BDSP). This encryption process uses a short-lived JSON Web Token (JWT), which is first signed (JWS) and then encrypted (JWE).

2. The decryption key for the JWT is derived a UUID known to the TPP, such as the InteractionId from the FAPI header or ConsentID.

3. LendingRates within the GET /accounts/{AccountId}/product payload are replaced with the encrypted rate. 

4. The TPP receives the /accounts/{accountId}/products payload with the encrypted LendingRates.

5. The TPP securely decrypts the encrypted LendingRates directly on the user's device, ensuring that the unencrypted values remain entirely local. At no point are the LendingRates transmitted to or stored on the TPP’s servers.

This approach enables the unencrypted LendingRates to be displayed to the end customer within the TPP’s user interface without ever being stored on the TPP’s servers.

Nebras is also considering providing all TPPs with a script that can be integrated into their front-end applications. This script would handle the decryption of encrypted LendingRates by processing the correct parameters passed in by the TPP. Beyond decryption, it would also inject the unencrypted values into a designated container — such as setting container.innerHTML = rate for an HTML element.

This approach offers two key benefits: first, it ensures consistency in how TPPs decrypt LendingRates, providing greater confidence in the process; second, it enhances ease of implementation for TPPs. The functionality would be somewhat similar to Stripe Elements (Stripe Elements | Custom Checkout Design and UI).

2.1.3 Business Rules to Support This Architectural Change

To maintain the integrity of the proposed solution, the following rules have been drafted and will be mandatory.

For LFIs:

1. LFI MUST NOT perform any operation beyond those explicitly described in this document for the encryption of LendingRates.

2. LFI MUST encrypt the LendingRates using JWE with A256GCM for content encryption.

3. LFI MUST assign a strict expiry time of 30 minutes from the moment of encryption to the JWT.

4. LFI MUST use the x-fapi-interaction-id (a UUID) provided in the header of the request as the actual symmetric decryption key.

5. LFI MUST set the kid in the JWE header to the string "InteractionId".

6. LFI MUST NOT encrypt any data other than the LendingRates within the GET /accounts/{AccountId}/product response.

7. LFI MUST NOT encrypt any data from any other Open Finance endpoint.

For TPPs:

1. TPP MUST NOT interact with the encrypted or unencrypted LendingRates in any manner other than as described in this specification.

2. TPP MUST perform all decryption of LendingRates locally on the user’s device, solely for the purpose of displaying these rates to the end user.

3. TPP MUST NOT transmit, store, or otherwise process the unencrypted LendingRates on their servers in any form or capacity.

4. TPP MUST submit their architectural plan for the decryption and display of LendingRates — including source code where applicable — to Nebras for inspection and approval.

5. TPP MUST present the decrypted LendingRates in a manner that is accurate, contextually appropriate, and faithfully represents the rates as provided by the LFI.

2.1.4 Discounted options

We have evaluated a number of alternative approaches:

1. The LFI sends the LendingRates unencrypted, with encryption happening within the API Hub. This approach was discounted as we aim to avoid the decrypted LendingRates ever being received by the API Hub.

2. The LFI sends the LendingRates directly to the end-user via another communication channel each time the TPP requests data from the GET /accounts/{AccountId}/product endpoint. This approach was rejected due to its negative impact on the customer experience and because it does not meet the requirement of displaying the underlying rate data within the TPP's user interface.While the approach outlined above is our recommendation, we are seeking input on specific aspects of it.

3. The LFI sends the LendingRates encrypted to the TPP via the API Hub, where either:

   1. the decryption key uses a shared secret tied to the user’s device (e.g., a mobile phone’s private key), or

   2. the decryption key uses a shared secret known by the TPP is a non-sensitive secret known only to the user and the LFI. Under this approach, the TPP would prompt the user to enter this secret via the TPP’s interface. The secret would not be stored by the TPP but would be used as part of the decryption process.

Options 3a and 3b introduce complexity for both LFIs and TPPs without providing additional security benefits. The risk we are addressing is not related to verifying the end user.