| Expand | ||||
|---|---|---|---|---|
| ||||
|
1. Introduction
LFIs must implement a Consent Management Interface (CMI) prescribed by standards to provide a User with information on their consents.
The Consent Manager API is used to retrieve consent-related data with which to populate the CMI. This guide explains how to use the API to retrieve User consent details, apply filtering and pagination, retrieve consent history, and map UI elements to API fields.
2. Retrieving User Consents
To retrieve all consents associated with a User (termed PSU in the Consent Manager) use the get /psu/{userId}/consents operation, where userId is the LFI unique identifier for the User.
...
Label | Operation | Property (JSONPath) | Guidelines | |
|---|---|---|---|---|
| 1 | TPP * Trading Name |
|
| |
| 2 | Total paid/Total paid to date |
|
| Sum that values indicated by the JSONPath that returned by this operation. |
| 3 | Permission Cancelled/Expired/Consumed |
|
| The statuses are all terminal states and the last update date will reflect when the consent was moved into that state. |
| 4 | Last payment made |
|
| |
| 5 | Payment to |
|
| Use the value of |
| 6 | IBAN |
|
| Use the value of |
| 7 | Reference |
|
| |
| 8 | Payment Purpose |
|
| The payment request provides the Aani purpose code, which must be transposed to the correct purpose code description based on Aani reference information. |
| 9 | From Account |
|
| The surrogate account identifiers patched onto the consent are returned. These must be replaced by the real IBAN by the LFI due restrictions on PII in the API Hub OR The debtor IBAN has been provided on the consent by the TPP, so the value of |
| 10 | Payment Rules |
|
| The properties show need to be based on the values found in control parameters, which differ based on the payment type. Please refer to the API description for available properties. |
| 11 | You started this permission |
|
| If the consent is part of a consent group, this must be the If a consent is not part of a consent group as |
| 12 | You cancelled this permission |
|
|
3. Connection History
To provide Connection History information to the User use the get /consent-groups/{consentGroupId}/consents operation. This returns all consents in a consent group, which are linked by the value of BaseConsentId.
...
Label | Operation | Property (JSONPath) | Guidelines | |
|---|---|---|---|---|
| 1 | TPP Trading Name |
|
| |
| 2 | Consent ID |
|
| |
| 3 | IBAN |
|
| The surrogate account identifiers patched onto the consent are returned. These must be replaced by the real IBAN by the LFI due restrictions on PII in the API Hub. |
| 4 | Data they get |
|
| Permissions must be provided using the standardised data cluster language provided in the Customer Data standards. The |
| 5 | <Connection date show as label> |
|
|
4. Payment History
To provide Payment History information to the User use the get /payment-log?consentId={consentId} operation. This returns a summary of all payments for a given consent.
...
Label | Operation | Property (JSONPath) | Guidelines |
|---|---|---|---|
TPP * Trading Name |
|
| |
Total paid/Total paid to date |
|
| Sum that values indicated by the JSONPath that returned by this operation. |
<Payment Date> |
|
| |
<Payment Reference> |
|
| |
<Amount> |
|
|
5. Status Code Language
The Consent Manager API provides consent statuses as codes. The codes should be normalized for display in the CMI
The table below maps a given code from a Consent Manager API status code to a CMI status code is mandated.
Consent Manager Status Code | CMI Status Code | |
|---|---|---|
| 1 | Rejected (where Rejected consents are returned, as the User identifier has been patched to the consent) | Rejected |
| 2 | AwaitingAuthorisation | Awaiting |
| 3 | Authorised | Active |
| 4 | Suspended | Suspended |
| 5 | Revoked | Cancelled |
| 6 | Consumed | Consumed |
| 7 | Expired | Expired |
If a code does not appear in this list it should be normalised based on the following rules:
Codes should be split on word boundary. For example “AwaitingAuthorization” becomes “Awaiting Authorization”.
Case should be maintained.
If the status requires truncation for display purposes the whole of the leftmost word should be returned. For example, “AwaitingAuthorization” becomes “Awaiting”.