| Table of Contents | ||||
|---|---|---|---|---|
|
1. Version Control
Version | Date | Description of Changes |
Bahrain OBF v1.0.0 | 25th Aug 2020 | Initial Release |
2. Overview
The Account and Transaction API Profile describes the flows and common functionality functionalities for the Accounts and Transaction API, which allows an Account Information Service Provider ('AISP') to:
Register an intent to retrieve account information by creating an "account access consent". This registers the data "permissions" and historical period allowed for transactions/statements - that the user/customer has consented to provide to the AISP; and
Subsequently, retrieve account and transaction data
...
Retrieve product specific information from ASPSP
2.1
...
Chapter Overview
This document chapter (Account Information Services) consists of the following parts:
Overview: Provides an overview of the profile.
Basics: Identifies the flows, release management and permission model.
Security & Access Control: Specifies the means for AISPs to authenticate themselves and provide consent.
Data Model: Documents mappings Mappings and enumerations that apply to all the end-points.
Alternative Flows: Documents rules Rules for alternative flows
...
2.2 Resources
Each of the Account and Transaction API resources are documented in the Resources and Data Models / AISP area of the specification. Each resource is documented with:
Endpoints
The API endpoints available for the resource
Data Model
Resource definition
UML diagram
Permissions as they relate to accessing the resource
Data dictionary - which defines fields, re-usable classes, mandatory (1..1) or conditional (0..1) as defined in the Design Principles section, and enumerations.0..1)
Usage Examples
...
3. Basics
...
3.1 Overview
The figure below provides a general outline of an account information request and flow using the Account Info APIs.
...
...
3.1.1 Steps
Step 1: Request Account Information
This flow begins with a user/customer consenting to allow an AISP to access account information data
Step 2: Setup Account-Access Consent-Consents
The AISP connects to the ASPSP that services the useruser’s/customer’s account(s) and creates an account-access-consentconsents resource. This informs the ASPSP that one of its userusers/customers is granting access to account and transaction information to an AISP. The ASPSP responds with an identifier for the resource (the ConsentId - which is the intent identifier). This step is carried out by making a POST request to / account-access-consents endpoint
The account-access-consent resource sresource will include these fields below - which describe the data that the user/customer has consented with the AISP:
Permissions - a list of data clusters that have been consented for access
Transaction Validity Period - the From/To date range which specifies a historical period for transactions and statements which may be accessed by the AISP
...
The AISP requests the user/customer to authorise the consent. The ASPSP may carry this out by using a redirection flow or a decoupled flow
In a redirection flow, the AISP redirects the user/customer to the ASPSP
The redirect includes the ConsentId generated in the previous step
This allows the ASPSP to correlate the account-access-consent consents that was setup
The ASPSP authenticates the user/customer
The ASPSP updates the state of the account-access-consent consents resource internally to indicate that the account-access consent -consents has been authorised
Once the consent has been authorised, the user/customer is redirected back to the AISP
In a decoupled flow, the ASPSP requests the user/customer to authorise consent on an authentication device that is separate from the consumption device on which the user/customer is interacting with the AISP
The decoupled flow is initiated by the AISP calling a back-channel authorisation request
The request contains a 'hint' that identifies the user/customer, paired with the consent to be authorised
The ASPSP authenticates the user/customer and updates the state of the account-access-consent consents resource internally to indicate that the account-access consent -consents has been authorised
Once the consent has been authorised, the ASPSP can make a callback to the AISP to provide an access token
The consent is managed between the user/customer and the AISP - so the account-access-consent consents details must not be changed (with the ASPSP) in this step. The user/customer will only be able to authorise or reject the account-access-consent consents details in its entirety
During authorisation, the user/customer selects accounts that are authorised for the AISP request (in the ASPSP’s banking interface)
...
This is carried out by making a GET request the relevant resourcea GET request the relevant resource
The unique AccountId(s) that are valid for the account-access-consent consents will be returned with a call to GET /accounts. This This will always be the first call once an AISP has a valid access token
...
3.1.2 Sequence Diagram
...
*CIBA - Client Initiated Backchannel Authentication
...
3.2 Idempotency
The API endpoints for creating account-access-consent consents resources are not idempotent.
If a time-out error occurs - then an AISP can create a new account-access-consent consents resource - rather than try with the same resource.
...
3.3 Release Management
This section overviews the release management and versioning strategy for the Account and Transaction API.
...
3.3.1 Account Access Consent
...
3.3.1.1 POST
An AISP must not create a Consent on a newer version, and use it on a previous version
E.g., A ConsentId for an account-access-consent consents created in v3, must not be used to access v2 endpoints
...
3.3.1.2 GET
An AISP must not access a Consent on an older version, via the Id for a Consent created in a newer version:
E.g., An account-access-consent consents created in v3 accessed via v2 account-request
An ASPSP must allow a Consent to be accessed in a newer version
An ASPSP must ensure Permissions set associated with a Consent are unchanged when accessed in a different version:
E.g., An account-request created in v2 will have the same details when accessed via v2 and v3 (as an account-access-consentconsents)
An ASPSP must ensure a Consent's fields are unchanged when accessed in a different version
An ASPSP may allow expired Consents to be accessed in a newer version
An ASPSP may choose to populate new fields introduced in a resource from previous version sensible defaults (if mandatory) or not populate at all (if not mandatory):
E.g., OBAccountAccessConsentResponse /Data/StatusUpdateDateTime introduced in v2 accessed with v1 AccountRequestId can be populated with Last accessed date time, if not already available in the system of records
...
3.3.1.3 PATCH
An AISP must not patch AISP must not patch a Consent on an older version, via an Id for a Consent created in a newer version:
E.g., An account-access-consent consents is created in v3, and request PATCH on v2
An ASPSP must support must support patching a Consent from a previous version via a newer version:
E.g., An account-request is created in v2, and request PATCH on v3
...
3.3.2 Account Information Resources
...
3.3.2.1 GET
An AISP may use a token that is bound to a Consent in a previous version, to access an endpoint of a newer version.
An AISP may use an Id for a Consent created in a previous version to retrieve Account Information resources in a newer version:
E.g., AccountRequestId from v2 can be used as ConsentId in v3, to GET /accounts
An AISP must not use an Id for a Consent from a newer version to access Account Information resources in a previous version:
E.g., ConsentId for an account-access-consent consents created in v3, must not be used to access v2 Account Information endpoints.
An ASPSP must allow an AISP to use an Id for a Consent from a previous version to access Account Information resource endpoints in a newer version:
E.g., AccountRequestId created in v2 must be allowed to access Account Information resource endpoints in v3.
An ASPSP must reject the request to access a resource, for which a Consent's Permissions set does not permit.
An ASPSP may choose to populate new fields introduced in a resource from previous version sensible defaults (if mandatory) or not populate at all:
E.g., OBAccountAccessConsentResponse /Data/StatusUpdateDateTime introduced in Version2 accessed with V1 AccountRequestId can be populated with Last accessed date time, if not already available in the system of records.
...
4.Security & Access Control
...
4.1 Scopes
The access tokens required for accessing the Account Info APIs must have at least the following scope:
accounts: Ability to read Accounts information
...
4.2 Grants Types
AISPs must use a client credentials grant to obtain a token to access the account-access-consents resource. In the specification, this grant type is referred to as "Client Credentials".
AISPs must use an authorisation code grant using a redirect or decoupled flow to obtain a token to access all other resources. In the specification, this grant type is referred to as "Authorisation Code").
...
4.3 Consent Authorisation
The AISP must create an account-access-consentconsents resource through a POST operation. This resource indicates the consent that the AISP claims it has been given by the user/customer to retrieve account and transaction information. At this stage, the consent is not yet authorised as the ASPSP has not yet verified this claim with the user/customer.
...
Once these steps are complete, the consent is considered to have been authorised by the user/customer.
...
4.3.1 Consent Elements
The Account Access Consent -access-consents resource consists of the following fields, which together form the elements of the consent provided by the user/customer to the AISP:
Permissions: The set of data clusters that the user/customer has consented to allow the AISP to access
TransactionFromDateTime: The earliest point of the transaction/statement historical period that the user/customer has consented to provide access to the AISP
TransactionToDateTime: The last point of the transaction/statement historical period that the user/customer has consented to provide access to the AISP
...
4.3.1.1 Permissions
Permissions codes will be used to limit the data that is returned in response to a resource request.
When a permission is granted for a "Detail" permission code (e.g., ReadAccountsDetail) it implies that access is also granted to the corresponding "Basic" permission code (e.g., ReadAccountsBasic).
While it is duplication for an AISP to request a "Basic" permission code and the corresponding "Detail" permission code, it is not a malformed request, and the ASPSP must not reject solely on the basis of duplication.
The permissions array must contain array must contain at least ReadAccountsBasic or ReadAccountsDetail.
The following combinations of permissions are not allowed, and the ASPSP must reject must reject these account-access-consents with a 400 response code:
Account Access Consents with an empty Permissions permissions array
Account Access Consents with a permission code that is not supported by the ASPSP (APSPSs are expected to publish which API endpoints are supported)
Account Access Consents with a Permissions array that contains ReadTransactionsBasic but does not contain at least one of ReadTransactionsCredits and ReadTransactionsDebits
Account Access Consents with a Permissions array that contains ReadTransactionsDetail but does not contain at least one of ReadTransactionsCredits and ReadTransactionsDebits
Account Access Consents with a Permissions array that contains ReadTransactionsCredits but does not contain at least one of ReadTransactionsBasic and ReadTransactionsDetail
Account Access Consents with a Permissions array that contains ReadTransactionsDebits but does not contain at least one of ReadTransactionsBasic and ReadTransactionsDetail
Permissions | Endpoints | Business Logic | Data Cluster Description |
ReadAccountsBasicReadAccountsBasic | /accounts |
| Ability to read basic account information |
ReadAccountsDetailReadAccountsDetail | /accounts | Access to additional elements in the payload | Ability to read account identification details |
ReadBalances | /balances |
| Ability to read all balance read all balance information |
ReadBeneficiariesBasicReadBeneficiariesBasic | /beneficiaries |
| Ability to read basic beneficiary details |
ReadBeneficiariesDetailReadBeneficiariesDetail | /beneficiaries | Access to additional elements in the payload | Ability to read account identification details for the beneficiary |
ReadDirectDebits | /direct-debits |
| Ability to read all direct read all direct debit information |
ReadTransactionsBasicReadTransactionsBasic | /transactions | Permissions must also include at least one of:
| Ability to read basic transaction information |
ReadTransactionsDetailReadTransactionsDetail | /transactions | Access to additional elements in the payload Permissions must also include at least one of:
| Ability to read transaction data elements which may hold silent party details |
ReadTransactionsCreditsReadTransactionsCredits | /transactions | Access to credit transactions. Permissions must also include one of:
| Ability to read only credit read only credit transactions |
ReadTransactionsDebitsReadTransactionsDebits | /transactions | Access to debit transactions. Permissions must also include one of:
| Ability to read only debit read only debit transactions |
ReadStatementsBasicReadStatementsBasic | /statements |
| Ability to read basic statement details |
ReadStatementsDetailReadStatementsDetail | /statements | Access to additional elements in the payload Access to download the statement file (if the ASPSP makes this available). | Ability to read statement data elements which may leak other information about the account |
ReadSupplementaryAccountInfo | /supplementary-account-info |
| Ability to read all product read all product information relating to the account |
ReadOffers | /offers |
| Ability to read all offer read all offer information |
ReadParty | /accounts/{AccountId}/party |
| Ability to read party information on the account owner |
ReadPartyCustomerReadPartyCustomer | /party |
| Ability to read party information on the user/customer logged in |
ReadFutureDatedPaymentsBasicReadFutureDatedPaymentsBasic | /future-dated-payments |
| Ability to read basic statement details |
ReadFutureDatedPaymentsDetailReadFutureDatedPaymentsDetail | /future-dated-payments | Access to additional elements in the payload |
|
ReadPAN | All API endpoints where PAN is available as a structured field | Request to access to PAN in the clear | Request to access PAN in access PAN in the clear across the available endpoints. If this permission code is not in the account-access-consentconsents, the AISP will receive a masked PAN. While an AISP may request to access PAN in the clear, an ASPSP may still respond with a masked PAN if:
|
...
4.3.1.1.a Detail Permissions
The additional elements that are granted for "Detail" permissions are listed in this section.
All other fields (other than these fields listed) are available with the "Basic" Permission access.
Permission - Detail Codes | Data Element Name | Occurrence | XPath |
ReadAccountsDetail | Account | 0..1 | OBReadAccount/Data/Account/Account |
ReadAccountsDetail | Servicer | 0..1 | OBReadAccount/Data/Account/Servicer |
ReadBeneficiariesDetail | CreditorAgent | 0..1 | OBReadBeneficiary/Data/Beneficiary/CreditorAgent |
ReadBeneficiariesDetail | CreditorAccount | 0..1 | OBReadBeneficiary/Data/Beneficiary/CreditorAccount |
ReadStandingOrdersDetail | CreditorAgent | 0..1 | OBReadStandingOrder/Data/StandingOrder/CreditorAgent |
ReadStandingOrdersDetail | CreditorAccount | 0..1 | OBReadStandingOrder/Data/StandingOrder/CreditorAccount |
ReadTransactionsDetail | TransactionInformation | 0..1 | OBReadTransaction/Data/Transaction/TransactionInformation |
ReadTransactionsDetail | Balance | 0..1 | OBReadTransaction/Data/Transaction/Balance |
ReadTransactionsDetail | MerchantDetails | 0..1 | OBReadTransaction/Data/Transaction/MerchantDetails |
ReadTransactionsDetail | CreditorAgent | 0..1 | OBReadTransaction/Data/Transaction/CreditorAgent |
ReadTransactionsDetail | CreditorAccount | 0..1 | OBReadTransaction/Data/Transaction/CreditorAccount |
ReadTransactionsDetail | DebtorAgent | 0..1 | OBReadTransaction/Data/Transaction/DebtorAgent |
ReadTransactionsDetail | DebtorAccount | 0..1 | OBReadTransaction/Data/Transaction/DebtorAccount |
ReadStatementsDetail | StatementAmount | 0..n | OBReadStatement/Data/Statement/StatementAmount |
ReadFutureDatedPaymentsDetail | CreditorAgent | 0..1 | OBReadFutureDatedPayment/Data/FutureDatedPayment/CreditorAgent |
ReadFutureDatedPaymentsDetail | CreditorAccount | 0..1 | OBReadFutureDatedPayment/Data/FutureDatedPayment/CreditorAccount |
...
Example behaviour of the Permissions for the ReadAccountsBasic and ReadAccountsDetail codes is as follows:
...
...
4.3.1.1.b Reversing Entries
It is expected that transactions will be returned in the payload irrespective of whether they are reversing entries, as long as the user/customer has provided consent for that type of transaction.
If the user/customer has provided permission for ReadTransactionsCredits, the ASPSP must include must include all credits, including debit reversals.
If the user/customer has provided permission for ReadTransactionsDebits, the ASPSP must include must include all debits, including credit reversals.
...
4.3.1.2 Transaction To/From Date Time
The TransactionToDateTime and the TransactionFromDateTime specify the period for consented transaction and/or statement history. Both the fields are optional and one may be specified without the other.
The AISP must be AISP must be restricted to accessing transactions within this period when accessing the transactions resource.
The AISP must be AISP must be restricted to accessing statements which are completely within are completely within this period when accessing the statements resource.
...
4.3.2 Account Access Consent Status
The Account Access Consent resource may have one of the following status codes after authorisation has taken place:
S. No. | Status | Description |
1 | Authorised | The account-access consent -consents has been successfully authorised. |
2 | Rejected | The account-access consent -consents has been rejected. |
3 | Revoked | The account-access consent -consents has been revoked via the AISP interface. |
...
4.3.3 Consent Re-authentication
Account Access Consents are long-lived consents.
A user/customer can re-authenticate an Account Access Consent account-access-consents if:
The account-access-consent has a status of Authorised
Where there is no change in the consent parameters required, AISPs should perform a re-authentication / refresh upon the original consent using the same intent-id as before, instead of issuing a new, duplicate consent.
An AISP and Userthe user/Customer customer may have multiple consents at any point in time.
...
4.4 Consent Revocation
A user/customer may revoke consent for accessing account information at any point in time.
The user/customer may request the AISP to revoke consent that it has authorised. If consent is revoked with the AISP:
The AISP must cease AISP must cease to access the APIs at that point
The AISP must call the PATCH operation AISP must call the PATCH operation on the account-access-consent consents resource (before confirming consent revocation with the user/customer) as soon as is practically possible, to indicate to the ASPSP that the user/customer has revoked consent
...
4.5 Access Revocation
A user/customer may revoke customer may revoke AISP's access directly with the ASPSP, via the access dashboard. In such a situation:
The ASPSPs must revoke must revoke the access token provided to the AISP
The status of the account-access-consent must remain consents must remain unchanged and the AISP must be AISP must be allowed to request user/customer to re-authenticate the same account-access-consent consents resource
Upon successful re-authentication by user/customer, an ASPSP may issue may issue new authorisation code and subsequently new access token to the AISP
...
4.6 Changes to Selected Account(s)
The user/customer must select customer must select the accounts to which the consent should be applied at the point of consent authorisation.
Subsequent changes to the set of accounts to which the consent authorisation applies may be applies may be carried out directly with the ASPSP. The method for doing this lies in the competitive space and is not part of this specification.
...
The account being closed
The account is barred or frozen
The beneficial owner of the account revokes the useruser’s/customer's mandate or power of attorney to operate the account
In these scenarios, only the affected account is removed from the list of selected accounts. The ASPSP must not revoke not revoke authorisation to other accounts.
...
5.Data Model
...
5.1 Using Meta to identify Available Transaction Period
For Accounts & Transaction APIs, the Meta section in API responses may contain two additional fields to indicate the date range for which data has been returned.
...
To ensure that the data is interpreted correctly, the ASPSP may provide may provide the date of the first available transaction and last available transaction as part of the response in the Meta section in the FirstAvailableDateTime and LastAvailableDateTime fields.
|
|---|
...
5.2 Enumerations
...
5.2.1 Static Enumerations
Code Class | Name | Definition |
OBAccountStatusCode | Enabled | Account can be used for its intended purpose. |
OBAccountStatusCode | Disabled | Account cannot be used for its intended purpose, either temporarily or permanently. |
OBAccountStatusCode | Deleted | Account cannot be used any longer. |
OBAccountStatusCode | ProForma | Account is temporary and can be partially used for its intended purpose. The account will be fully available for use when the account servicer has received all relevant documents. |
OBAccountStatusCode | Pending | Account change is pending approval. |
OBAddressTypeCode | Business | Address is the business address. |
OBAddressTypeCode | Correspondence | Address is the address where correspondence is sent. |
OBAddressTypeCode | DeliveryTo | Address is the address to which delivery is to take place. |
OBAddressTypeCode | MailTo | Address is the address to which mail is sent. |
OBAddressTypeCode | POBox | Address is a postal office (PO) box. |
OBAddressTypeCode | Postal | Address is the complete postal address. |
OBAddressTypeCode | Residential | Address is the home address. |
OBAddressTypeCode | Statement | Address is the address where statements are sent. |
OBBalanceTypeCode | ClosingAvailable | Closing balance of amount of money that is at the disposal of the account owner on the date specified. |
OBBalanceTypeCode | ClosingBooked | Balance of the account at the end of the pre-agreed account reporting period. It is the sum of the opening booked balance at the beginning of the period and all entries booked to the account during the pre-agreed account reporting period. |
OBBalanceTypeCode | ClosingCleared | Closing balance of amount of money that is cleared on the date specified. |
OBBalanceTypeCode | Expected | Balance, composed of booked entries and pending items known at the time of calculation, which projects the end of day balance if everything is booked on the account and no other entry is posted. |
OBBalanceTypeCode | ForwardAvailable | Forward available balance of money that is at the disposal of the account owner on the date specified. |
OBBalanceTypeCode | Information | Balance for informational purposes. |
OBBalanceTypeCode | InterimAvailable | Available balance calculated in the course of the account servicer's business day, at the time specified, and subject to further changes during the business day. The interim balance is calculated on the basis of booked credit and debit items during the calculation time/period specified. |
OBBalanceTypeCode | InterimBooked | Balance calculated in the course of the account servicer's business day, at the time specified, and subject to further changes during the business day. The interim balance is calculated on the basis of booked credit and debit items during the calculation time/period specified. |
OBBalanceTypeCode | InterimCleared | Cleared balance calculated in the course of the account servicer's business day, at the time specified, and subject to further changes during the business day. |
OBBalanceTypeCode | OpeningAvailable | Opening balance of amount of money that is at the disposal of the account owner on the date specified. |
OBBalanceTypeCode | OpeningBooked | Book balance of the account at the beginning of the account reporting period. It always equals the closing book balance from the previous report. |
OBBalanceTypeCode | OpeningCleared | Opening balance of amount of money that is cleared on the date specified. |
OBBalanceTypeCode | PreviouslyClosedBooked | Balance of the account at the previously closed account reporting period. The opening booked balance for the new period has to be equal to this balance. Usage: the previously booked closing balance should equal (inclusive date) the booked closing balance of the date it references and equal the actual booked opening balance of the current date. |
OBCreditDebitCode | Credit | Operation is a credit |
OBCreditDebitCode | Debit | Operation is a debit |
OBEntryStatusCode | Booked | Booked means that the transfer of money has been completed between account servicer and account owner. Usage: Status Booked does not necessarily imply finality of money as this depends on other factors such as the payment system used, the completion of the end- to-end transaction and the terms agreed between account servicer and owner. Status Booked is the only status that can be reversed. |
OBEntryStatusCode | Pending | Booking on the account owner's account in the account servicer's ledger has not been completed. Usage: this can be used for expected items, or for items for which some conditions still need to be fulfilled before they can be booked. If booking takes place, the entry will be included with status Booked in subsequent account report or statement. Status Pending cannot be reversed. |
OBEntryStatusCode | Interimpending | Booking on the account owner’s account is complete but may be reversed due to other factors such as payment system failure, non completion of end-to-end transaction, etc. |
OBExternalAccountSubTypeCode | ChargeCard | Account sub-type is a Charge Card. |
OBExternalAccountSubTypeCode | CreditCard | Account sub-type is a Credit Card. |
OBExternalAccountSubTypeCode | CurrentAccount | Account sub-type is a Current Account. |
OBExternalAccountSubTypeCode | EWallet | Account sub-type is an EWalletE-Wallet |
OBExternalAccountSubTypeCode | Loan | Account sub-type is a Loan. |
OBExternalAccountSubTypeCode | Mortgage | Account sub-type is a Mortgage. |
OBExternalAccountSubTypeCode | PrePaidCard | Account sub-type is a PrePaid Card. |
OBExternalAccountSubTypeCode | Savings | Account sub-type is a Savings. |
OBExternalAccountSubTypeCode | Deposit | Account sub-type is a Deposit/Investment account. |
OBExternalAccountTypeCode | Business | Account type is for business. |
OBExternalAccountTypeCode | Personal | Account type is for personal. |
OBExternalCardAuthorisationTypeCode | ConsumerDevice | Card authorisation was via a Consumer Device Cardholder Verification Method (CDCVM) |
OBExternalCardAuthorisationTypeCode | Contactless | Card authorisation was via Contactless. |
OBExternalCardAuthorisationTypeCode | None | No card authorisation was used. |
OBExternalCardAuthorisationTypeCode | PIN | Card authorisation was via PIN. |
OBExternalCardSchemeTypeCode | AmericanExpress | AmericanExpress scheme. |
OBExternalCardSchemeTypeCode | Diners | Diners scheme. |
OBExternalCardSchemeTypeCode | JCB | JCB scheme. |
OBExternalCardSchemeTypeCode | MasterCard | MasterCard scheme. |
OBExternalCardSchemeTypeCode | VISA | VISA scheme. |
OBExternalLimitTypeCode | Available | The amount of credit limit available to the account holder |
OBExternalLimitTypeCode | Credit | The amount of a credit limit that has been agreed with the account holder |
OBExternalLimitTypeCode | Emergency | The amount of an arranged lending limit that can be borrowed on top of pre-agreed lending, that has been agreed with the account holder |
OBExternalLimitTypeCode | Pre-Agreed | The amount of an arranged lending limit that has been agreed with the account holder |
OBExternalLimitTypeCode | Temporary | The amount of a temporary lending limit that has been agreed with the account holder |
OBExternalOfferTypeCode | BalanceTransfer | Offer is a balance transfer. |
OBExternalOfferTypeCode | LimitIncrease | Offer is a limit increase. |
OBExternalOfferTypeCode | MoneyTransfer | Offer is a money transfer. |
OBExternalOfferTypeCode | Other | Offer is of other type. |
OBExternalOfferTypeCode | PromotionalRate | Offer is a promotional rate. |
OBExternalPartyTypeCode | Delegate | Party that has delegated access. |
OBExternalPartyTypeCode | Joint | Party is a joint owner of the account. |
OBExternalPartyTypeCode | Sole | Party is a sole owner of the account. |
OBExternalFutureDateTypeCode | Arrival | Future Dated payment date is specified as the arrival date for the recipient |
OBExternalFutureDateTypeCode | Execution | Future Dated payment date is specified as the execution date |
OBExternalStandingOrderStatusCode | Active | The standing order is active. |
OBExternalStandingOrderStatusCode | Inactive | The standing order is inactive. |
OBExternalStatementTypeCode | AccountClosure | Final account closure statement. |
OBExternalStatementTypeCode | AccountOpening | First statement provided for an account. |
OBExternalStatementTypeCode | Annual | Annual statement report. |
OBExternalStatementTypeCode | Interim | Adhoc or customised statement period. |
OBExternalStatementTypeCode | RegularPeriodic | Regular pre-agreed reporting statement. |
...
5.2.2 ISO Enumerations
These following ISO Enumerations are used in the Account APIs.
ISO Data Type | Fields | ISO Enumeration Values URL |
Min3Max4Text | MerchantCategoryCode | |
ActiveOrHistoricCurrencyCode | Currency | |
CountryCode | Country | |
ExternalBankTransactionFamilyCode | BankTransactionCode/Code | |
ExternalBankTransactionSubFamilyCode | BankTransactionCode/SubCode |
...
5.2.3 Namespaced Enumerations
The enumerated values specified by Open Banking are documented in Swagger specification.
...
6. Swagger Code
The swagger code file for the Sharing Transaction History/ Account Information and Sharing Product Details APIs can be accessed at this link.
...