# Introduction
### Disclaimer
Open Banking Nigeria (OBN) standard specified within this document does not constitute a legal framework as such any institution that adopts the standard is not obliged to any legal entitlements by OBN or other participants and vice versa. Furthermore, the standard defines a minimum set of requirements for participants, but by no means a complete or conclusive list. Participants are encouraged to employ best-in-class industry practices, judgement and processes for their specific infrastructure, environment and services. Similarly, regarding regulations and compliance by participants, adherence to this standard by no means indicates compliance or exemption from governing regulations and laws. While the standard is designed to be consistent with prevailing regulations and laws, If there are any disparities between this standard and such laws or regulations, those regulations and laws should supersede this standard. Participants are wholly responsible for their compliance with all regulations and laws that apply to them.
### Intended Audience
This document is intended for members of the financial and payment services community but is also publicly available to all parties interested to learn about Open Banking.Financial institutions intending to provide secure access to customer financial data for other financial institutions, technology companies and service providers should employ this document as a framework to guide the development, provisioning and operation of open APIs.Service Providers, Payment Solutions companies and other financial institutions that wish to access customer data within other financial institutions operating within the Open Banking network can easily adapt and integrate to such institutions by integrating to the APIs according to the guidelines and specifications outlined within this document and subsequently re-use the same integration assets to connect to multiple "open" financial institutions. Members of the public can learn about the imperatives for Open Banking and its role in the evolution of banking and financial services. Users can get a general understanding of the obligations of their account custodians, channel and service providers in the Open Banking scheme. Aspects such as security, service levels and dispute handling may also provide clarity and an appreciation for the inner workings of the interested user but most importantly, transparency and understanding of the users' rights within the system.
# Terms And Definitions
| Abbreviations | Definition |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 2FA | Second Factor Authentication / Strong Authentication |
| API | Application Programming Interface |
| AP | Account Provider as defined within this document |
| DMZ | Demilitarized Zone (pertaining to TCP/IP Networks) |
| Fintech | A Financial and Technology Services Company |
| FPSP | Financial and Payment Services Providers |
| GUID | Global Unique Identifier |
| MLS | Message Level Security. In the context of this document, this refers to Message Signing. |
| MPR | Monetary Policy Rate |
| NDPR | Nigeria Data Protection Regulation |
| NITDA | National Information Technology Development Agency |
| OLTP | Online Transaction Processing |
| OLAP | Online Analytic Processing |
| TPP | Third-Party Provider as defined within this document |
| Transaction | A request to a financial institution to authorize the disbursement of goods or performance of services on behalf of a customer based on funds the customer has with the financial institution. |
| UUID | User Unique Identifier |
# Third-Party Provider Integration
OBN provides a self-test environment to simulate AP responses to TPPs. TPPs are however not issued a letter of completion by OBN due to the diverse nature of their offerings, platforms, operations and the lack of end-to-end visibility. Only sandbox procedures are required for TPPs.
To get started, TPPs will need to register on OBN portal designating personnel for the relevant roles and providing the requested information. Any number of users can create profiles as these are independent and do not identify with an institution.\
Simulation credentials are provisioned for each account registered including:
1. An assigned Client ID
2. Client Secret (Base 64 encoded) – applied to message signing.
3. A RSA public key component for encryption
4. A key-group ID
5. A signed certificate
TPPs may run simulations with these credentials against OBN sandbox APIs. A test script is provided for the TPPs to self-validate the exchanges and expectations at their end.\
Test Script: To be determined after agreeing on a working set of APIs and required functionality
# Account Provider Certification
OBN provides a sandbox environment that simulates TPP messages against AP endpoints as a way to assess the AP's API functionality and performance. Financial Institutions will have to pass all test cases of the self-assessment or provide reasonable justification for any exceptions to be accredited by OBN as qualified APs.
Updates to OBN API specifications will be released in 6-month cycles except security related releases which may be published ad-hoc. APs are required to update and re-certify their endpoints within a year of the published update date, following which the latest OBN update will make the previous changes mandatory which may invalidate non-compliant AP integrations. Security updates will be effected along with the last update before the security patch except critical updates which will be communicated by OBN to certified APs. In addition, any major changes to an AP's environment such as changes to API endpoints, software platform including SDKs, runtime environments and libraries, or major internal service functionality should warrant APs to recertify their integrations.\
The certification process takes the institution through sandbox, pre-production and in-production stages.
**Getting Started**
{% hint style="info" %}
The OBN self-certification process is under development. The process below is therefore not applicable until otherwise communicated by OBN.
{% endhint %}
To get started with self-certification, commercial banks and other FPSPs that qualify as APs will need to register on OBN portal ([https://openbankingng.org](https://openbankingng.org/)), select and provide the required details under the "Account Provider" tab. The profile should be created with an abstract or group email address, for example [*obnadmin@abcbank.com*](mailto:obnadmin@abcbank.com). This is required for posterity in case the primary individual(s) working on the project are no longer with the institution. At most two individuals, but preferably one per time should be included in this group as admins of the FPSP. To update the admin personnel credentials, simply remove older user(s) from the mail group and add the new user(s), perform a password reset on OBN portal so the new user receives the reset link. Alternatively, OBN can be contacted through formal channels to update the credentials against the FPSP's profile.
Subsequently, the AP administrator will need to create roles and assign individuals within the organization that will be responsible for:
1. **Security:** This role is responsible for managing access credentials related to the APIs including session keys, certificates and encryption key pairs. While OBN portal only participates in the sandbox testing, it is expected that the procedures employed here should prepare this user for their role in the production environment.
2. **Development:** This role is in charge of API development and would have access to setup relevant configuration such as the base URL, simulator parameters for functional, exception and load tests.
3. **Communication:** APs, once certified, can leverage the OBN portal to communicate developments regarding their OBN services and offerings to the general public. This has the advantage of aggregating and presenting information from all participants within a single portal to constantly engage with followers of the network.
Designated personnel for these roles will receive emails from OBN to provide access credentials.
# Pre-production Setup
Similar credential exchanges are required for the pre-production environment setup. If lost, misplaced or compromised, the framework allows new credentials to be generated with a grouping schema. A security profile group consists of a collection of credentials. A group ID is assigned to each group and will be sent along with all calls to the APIs. Only two (2) group IDs can be active per time and the security admin can enable new security groups or disable an older group as required.
Once the simulated tests have been passed in sandbox, a "move to pre-production" link is activated to transition the AP into pre-production. It is expected that the AP has also migrated API and internal services into their production environment at this time. Similar callback URL and certification account details are required to commence the self-service certification program.
This program performs good-path, exception and performance tests of the production APIs that helps confirm the features have been migrated correctly and are working as expected in production. In addition, and most importantly, the performance tests would reveal if any APIs are functioning below capacity given the simulated load. These metrics would be red flagged for the AP to tune and rerun the certification. If all metrics pass, the certification program is deemed complete.
# Production Ready
Completing the certification course means an institution's APIs are production ready. A letter of completion is issued to the AP admin personnel through their designated email and all production credentials are deleted from their OBN profile within 15 business days of completing the certification; however, the certification results are preserved. OBN will subsequently publish the AP's logo and date of completion on the portal.
Internally, there may be additional work to be done to establish new processes with the relevant stakeholders within the institution.
# Sandbox Testing
Once a profile has been created for the institution and designated roles filled, the AP security personnel will have access to download the security credentials which should be legibly displayed on the dashboard of their profile. Only the sandbox pane will be active until the institution passes the required tests. Credentials required on the AP's endpoint are:
1. An assigned client ID
2. OAuth access token
3. Client Secret (Base 64 encoded) – applied to message signing.
4. RSA public key for sensitive field encryption.
5. A key-group ID
6. Certificate Signing Request
OBN provides a test Certificate Signing Request (CSR) simulating the functions of a TPP. This should be downloaded, signed within the AP's certificate management environment and the signed certificate uploaded in the provisioned widget.\
The development personnel will need to configure a global API URL which forms the base URL for all API call paths. The user should also ensure that OBN sandbox IP (X.X.X.X / X:X:X:X:X:X:X:X) has been permitted or whitelisted across all necessary network firewalls. A poll button is provided for the user to check connectivity to the **base/poll** URI path. A log of these tests is provided to show any restrictions or errors the poll test encounters. If polling succeeds, the configuration is accepted. The simulator pane becomes enabled. The development personnel should supply all listed credentials such as test accounts, customer IDs etc. that will be used for functional testing.\
Individual API calls can be tested with the "TEST" widget and code samples provided beside each API specification on the web portal. However, the development personnel must run the full simulation to pass all test cases and move to the pre-production environment. The simulation would include good-path and exception tests.\
Sandbox progress and simulation results are published on all user dashboards within the organization across the following stages:
1. Setup
2. API development
3. Functional Testing
4. Exception Testing
5. Migrating to pre-production
# API Architecture
{% hint style="info" %}
All APIs within this framework are RESTFUL and support JSON payload formats. The APIs are grouped into four (4) categories based on their functions:
{% endhint %}
### Registration APIs
This group lists APIs that manage access and permissions within each AP domain. The registration framework requires TPPs and individual consumers to be registered and subsequently access just the services that have been permitted with accompanying proof of consent.
TPPs may apply this set of APIs to onboard with APs or get setup by the APs manually. APs are to perform due diligence after which they can approve TPP registrations, allowing access to groups or specific APIs that the TPP is permitted on behalf of customers. Registration of TPPs provides system-level credentials to the TPP application necessary to access other API categories in the framework.
Customers accessing their accounts through registered TPPs must be registered with their APs by creating TPP specific registration records. Registration for consumers provides tokens that permit only that TPP to access the user-specified Account Number within the AP's domain. Also at the user level, each registration record should specify the APIs and functions the user has provided consent to the TPP to access.
APs are at liberty to permit, deny or revoke access as deemed necessary. This is further elaborated in the Security guidelines and API specifications.
### Meta-Directory APIs
This group contains APIs that provide cacheable listings including but not limited to financial institution names and assigned codes, product and service identifiers, response code directory and performance information. Data provided by these APIs change less frequently and can be polled on a scheduled basis. Some of these are also static and provided within this documentation.
### Open-Data APIs
This collection of APIs provide access to financial institution data such as channel information, for example ATM, POS and Bank Branch locations. TPPs should be granted access to their required data APIs by APs at the institution level.
### Payment APIs
This collection of APIs consists of READ and WRITE APIs. READ APIs provide consumer information e.g. Accounts balances, BVN, Transaction History, Indebtedness and debt profile/history, standing instructions etc. WRITE APIs result in the movement of financial value either per transaction (as in the case of individual payments) or in-bulk (e.g. inter-member settlements, disbursements, single debit-multiple credit etc.)
# Messaging Standard
### Message Headers
Each payload in the Open Banking system may include the following header elements:
| | Header | Description | Requirement |
| -- | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
| 1 | On-behalf-of Participant | If several TPPs participate in the messaging chain, this field indicates the name of the originating TPP assigned or known to the last-mile TPP | Conditional |
| 2 | Client ID | ID of the TPP assigned by the AP. This only applies to the last mile connection of TPPs to APs | Conditional |
| 3 | Daily Message Serial Number | A serial number for tracking messages sent/received between two participants daily | Optional |
| 4 | Unique Message Key (or idempotency key) | The key is the single unique reference across all systems and should be maintained across the value chain (even across multiple TPPs) | Mandatory |
| 5 | Logical Message Sequence Number | Used only if the payload is part of a sequence of messages | Optional |
| 6 | Message Signature | The content of the message signature differs for each payload depending on fields categorized as sensitive. Please see the section on Message Security for further details on how to deduce and use this field. | Mandatory |
| 7 | Request Message Sent Epoch Time | Populated by the initiator (typically a TPP) in a request message | Mandatory |
| 8 | Request Message Received Epoch Time | Populated by the recipient (typically an AP) in a response message | Mandatory |
| 9 | Request Processing Completed Epoch Time | Populated by the recipient. Identifies the time at which the request has passed the API screening and forwarded to perform the requested system function. | Optional |
| 10 | Response Processing Started Epoch Time | Populated by the recipient. Identifies the time at which the system function has been completed and control handed back to the API to respond. | Optional |
| 11 | Response Message Sent Epoch Time | Populated by the recipient in the response payload | Mandatory |
| 12 | Response Message Received Epoch Time | Populated by the initiator in the response payload | Mandatory |
| 13 | Next Page | Used to populate the URL to the next page in a paged response payload | Conditional |
| 14 | Key / Group ID | A numeric identifier indicating the version of security credentials that apply to this API call. Refer to the Security Guidelines for a list of these credentials. | Mandatory |
\
The viability and usefulness of a numeric identifier per institution assigned by OBN is also under consideration. The objective is to identify the initiating and recipient institutions across the complete message trajectory. If determined to be viable, the fields will be updated in future releases of the API specifications. Currently APs and TPPs are advised to support the placeholders indicated in the API specifications but allow for them to be blank or null populated.
The timestamp headers help institutions, particularly TPPs identify and analyze transient delays in message processing to proactively identify any processing bottlenecks. Other essential message header fields are indicated in the API specifications.
### Message Integrity
Participants must unequivocally receive and validate responses before an exchange can be deemed complete. Where an exchange is incomplete either by way of a response time-out, erroneous response structure, or content validation errors, remedial steps must be taken by the initiating participant to ensure that any financial changes within the recipient's system are rolled back *immediately* and where not immediately possible, maintain a retry mechanism with frequencies tailored to the sensitivity of the operation to a maximum of **6 hours**. Finally, where these steps fail, the records should be escalated for manual treatment by personnel of the organization. Recovery action varies for different APIs and may not be necessary altogether for Open Data and META Directory type of APIs which are inherently READ APIs.\
Payment APIs or other APIs involved in change operations such as INSERT, UPDATE or DELETE operations, notwithstanding their financial significance, should indicate the state of completion of the operation. State definitions are subject to internal system operated by the participant but at the minimum should indicate:
1. Request-in and Request-out status: captures the state of the request received by the entity and the request sent to any other participating entity in the value chain (if relevant)
2. Response-in and Response-out status: shows whether the entity in question has received a response for the operation from the upstream provider (where relevant) and also whether a response has been sent to the downstream requester.
As a guide, a simple prescription for a database structure is to maintain 7 columns per operational record that indicates with timestamps or null values the request/response in and out timestamps (taking up 4 columns), one column for the response state i.e. either valid or invalid or non-existent and the last 2 columns as the retry/cancellation request and response timestamps. Operations that have exceeded their permissible timeout periods or respond with format or validation errors should update the response status accordingly which could trigger an asynchronous process to start a retry/cancellation call based on the status and type of operation.
### Idempotency
The APIs support idempotency for safely retrying POST transactions without accidentally performing the same operation twice. This is useful when an API call is disrupted, and no response has been received. For example, *request\_time\_out* or *response\_received\_too\_late*. Therefore, if a response message is not received for a transaction, the request can be retried (if suitable for the transaction) with the same idempotency key, with a guarantee that no more than one transaction would be posted.
To perform an idempotent request, an Idempotency-Key: header must be included in each request.
Idempotency works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeded or failed. Subsequent requests with the same key should return the same result, including Server (500) errors.
An idempotency key is a unique value generated by the initiating TPP which the server uses to recognize subsequent transaction retries of the same request. It is up to the TPP to determine how these idempotency keys would be generated. Whatever it is, it must have enough entropy to avoid collisions. Idempotency keys are not time-limited and should be unique for the lifetime of the connected endpoints.
Furthermore, Idempotency keys should only be stored by the receiving AP endpoint if the payload passes initial screening for structure, format and key-field validation and has commenced internal processing within the API function that was called. If incoming parameters failed validation, or the request conflicted with another that was executing concurrently, no idempotent result is saved because no API endpoint began execution. It is safe to retry these requests.
All POST requests accept idempotency keys and all transaction API calls must have idempotency keys. Sending idempotency keys in GET and DELETE requests has no effect and should be avoided, as these requests are idempotent by definition.
### Timeouts
The maximum allowable timeout period for each API call is defined per API category/group. Registration and Meta Directory operations have a maximum timeout of 90 seconds, Open Data operations 45 seconds and Payment operations 30 seconds. Subject to SLAs, stricter timeout settings can be employed between TPPs and APs and may vary per API if those variations are easily managed by both parties.
### Paging
For endpoints that provide a potentially long list of records, the response may be paged depending on the total number of records that the server can return at a time. This maximum setting is subject to the server capabilities. Within open banking specifications, APIs that are to be paged are implemented with http GET verb.
To retrieve the full dataset in this category, the requester may need to submit several requests. The first request would typically assume the complete data set will be returned and therefore make no reference to paging. If the server determines that paging is required, the server participant will be required to populate a NextPage response header with a URI link to the next page which should indicate the ***start\_id**, **limit*** and \**enum*
* Paging details should go in the Message Response Header section query parameters already pre-populated by the server. The enum parameter is a temporary GUID that provides a reference to the object being queried which the server may have cached or mapped to a database query. The initiator (typically a TPP) could easily use this link as the request URI to fetch subsequent pages. OBN recommends that servers retain result sets or cached query maps for at least 5 minutes before purging from memory. Where a paged request is made with a GUID that has been purged, the server should return a HTTP 50Xor just 404.50X implies the data might be there once the server has rectified error. requiring the initiator to restart the query with the initial payload.
This architecture requires that cached paged records on the server-side are ordered with serial numeric identifiers which could be dynamically allocated to a dataset based on date/time-sorting or some other method of ordering the dataset records. Dynamic sorting or filtering is not supported by OBN APIs. The TPP may employ sorting and filtering logic to cached data within the user's session after pulling from APs.
### Naming Convention
Most fields in the API specifications are designated in lowercase with underscores separating each parameter-word to keep the fields easily readable and as close to their representative meaning as possible. All field names are strictly alphanumeric. No other notable conventions are applied in this version.
### Data Types and Formats
The following data types and format conventions will be used in OBN APIs:
| Type | Format | Description |
| --------------- | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| String | \[A-Z]\[a-z]\[0-9] | Does not include special or non-printable characters. |
| Boolean | Enum | Valid values are ("true",”1”) or ("false",”0”) |
| Amount | \[0-9].\[0-9],length:2\|3 | Amounts must always be represented with dot and proceeded with the number decimals for the currency in question even where no decimal values are present. A maximum of 12 major digits are allowed. |
| AccountType | Enum | CURRENT, SAVINGS, CREDIT, INVESTMENT, MORTGAGE, WALLET, PREPAID, LOAN, OTHER |
| AccountNumber | \[0-9], length:10 | The NUBAN Account format |
| PhoneNumber | +\[0-9], length:1-3, ”-“\[0-9] | Must be in international format e.g. +234-8032148373 |
| CurrencyCode | \[A-Z]\[0-9], length:3 | Currency code in ISO 4217 format in either numeric or alphanumeric format |
| CurrencySymbol | \[A-Z], length:1-3 | Display symbol for the currency e.g. “N” or “NGN” used to render the amount on screen or in receipts. |
| Date | yyyyMMdd | These date formats should be applied to API exchanges to limit errors. |
| DateTime | yyyyMMddHHmmssfff | |
| JulianDate | YDDD | |
| Timestamp | YDDDnnnnnnnnn | |
| DisplayDate | yyyy/MM/dd | These date formats should be applied for display purposes only |
| DisplayTime | HH:mm:ss (fff) - optional | |
| DisplayDateTime | yyyy/MM/dd HH:mm:ss fff | |
| EpochDateTime | \[0-9] | UTC date in epoch milliseconds. i.e. time between current millisecond and 1970-01-01 00:00:00 000 |
| CountryCode2 | \[A-Z], length:2 | Country code in ISO 3166-1 alpha-2 format, e.g. "NG" |
| CountryCode3 | \[A-Z], length:3 | Country code in ISO 3166-1 alpha-3 format, e.g. "NGA" |
### Message Security
OBN APIs are secured at multiple levels in the data exchange stack ranging from identity verification, access and permission management to network, message and field level security mechanisms. This section describes the security protocols employed at the message and field levels only. For more information regarding the complete security framework, please refer to *the OBN Security Framework and Guidelines* section within this document.
Message Level Security is accomplished with *Message* *Signing*. *Message* *Signing* involves generating a SHA512 hash of data that distinctly qualifies a message payload. This typically is a collection of message fields that are considered a distinct representation of the message and its contents in addition to certain control fields. *Message* *Signing* is required to ensure that if the message payload is intercepted either before the Transport layer encryption or within, the recipient can validate the authenticity of the message content before processing and decline if not found to match the indicated request details. Note that this feature is not to be confused with *Message* *Encryption* where the full API payload is encrypted with an asymmetric key pair. The underlying reason is that OBN has decided NOT to encrypt the full payload to eliminate the decryption overhead required to log such message exchanges and also to allow requisite fields to be easily identifiable in the logs.
To prevent replay attacks, the signature includes the time at which the message was sent and the idempotency key. After signature validation, the timestamp is checked to ensure that the message is current and does not exceed the system time by more or less than 3 minutes allowing for marginal system time disparities. The payload from the sending party is expected to contain the Message Signature header which will be recalculated by the recipient with the same agreed fields and compared for validation. Note that fields must be combined in the order in which they are documented prior to encryption.
Message Signing is defined on a "per-API" basis because all payloads do not require this level of scrutiny. The API specifications indicate APIs that require message signing. At the field level, sensitive fields (prefixed with 'x') are also to be encrypted directly by the sender using the public key provided and decrypted by the recipient's application for verification and further processing.
### Event Logging
To keep a reasonable trail of API activity, logs are required for all requests and responses to be kept for at least 180 days by APs and TPPs. Participants will need to assess the requirements and provide sufficient infrastructure given the volumes they expect and peak period loads.
Logs should be kept for ALL messages received in raw first, and optionally log in formatted layout before any business logic processing is performed. Likewise, outgoing messages should be logged once constructed after all internal processing just before being sent.
# Performance Monitoring
To monitor API performance and by inference, the performance of underlying systems, APs and TPPs should provide built-in performance metric gathering into their APIs. For APs, this information *may* be published in the Meta Directory under the Get Performance API call. If published, TPPs can query this information on a scheduled basis to determine which APs are operating optimally per time and may apply this intelligence to load scheduling and optimal path routing.
However, TPPs can make such decisions using metrics they maintain if not published by APs via APIs. Note that reporting requirements of this standard instruct that APs must provide monthly reports showcasing these performance metrics in daily summary and detailed formats. Alternatively, APs can provide performance monitoring dashboards which registered TPPs can access at any time to generate reports or locate patterns.
The following types of performance information are required from all APIs published by APs:
| | Metric | Description |
| -- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| | | |
| 1 | msg\_validation\_time | Average time it takes to validate the message e.g. sender authentication, time stamp checking, message signature verification, Authentication token verification, message fields validation etc. |
| 2 | network\_proc\_time | Network processing time i.e. time between the timestamp in the request message and the timestamp on the API server at the time of receipt. |
| 3 | avg\_db\_time | Average time it takes to perform database operations |
| 4 | avg\_ext\_call\_time | Average time it takes to perform subroutine API calls from within the API |
| 5 | avg\_log\_time | Average time it takes to log API calls. |
| 6 | avg\_total\_proc\_time | Average total processing time i.e. time between receiving a request and dispatching a response. |
| 7 | avg\_req\_proc\_time | Average request processing time i.e. time between when a request is received and dispatched to internal micro-services for processing |
| 8 | avg\_rsp\_proc\_time | Average response processing time i.e. time between when a response is received internally, formatted and sent to the client system. |
| 9 | total\_api\_calls | Total number of API calls processed |
| 10 | %\_success | Relates to messages successfully received, unpacked and responded to |
| 11 | %\_approved | Relates to messages that achieved the function for which the call was made. |
| 12 | calls\_per\_sec | Average calls per second. |
\
APs should record individual API performance metrics with at most 5 minute intervals between data points. Any interval missed is assumed to be downtime except within a period coinciding with a scheduled change or maintenance activity. For investigative purposes, these metrics can also be kept on a transactional level at the discretion of the AP.\
In addition, APs are required to provide API availability metrics. These metrics should be collected:
1. From outside the APs' networks
2. Over the internet
3. Through at least two major Internet Service Provider routes.
4. Per API endpoint e.g. one for branch related methods, another for ATM related methods etc.
The metrics give an external view of the organization's availability cutting across network, operating systems and application layers. External solutions or organizations can be engaged to provide and publish this data on behalf of APs.
# Hashmaps and Lookups
Hashmaps and Lookups contain relatively static content throughout the API lifetime. This content is however crucial for processing such as a map of response codes to response descriptions. Relevant mappings are provided within the API specifications under the META Directory collection.
Developers are advised to store this information in persisted format e.g. within a database, a database table or system file in a way that they can be dynamically updated and reloaded within their applications. For instance, a mapping reference called ***response\_code\_descriptions*** can be created with response code to response description mapping as columns in a database table. This table can be called up at intervals and loaded into the application memory or upon an application restart. New definitions of response code and descriptions can simply be updated in this table if/when any updates arise. This structure is especially useful for self-defined mappings for which allowances have been provided in the specifications.
# Standard
* Design Principles
* Rationale
* Governance
* Participants and Roles
* Systems Architecture
* Value Proposition
* Summary
* FAQs
### Design Principles
Open APIs are public (i.e. accessible over the internet) interfaces to proprietary systems made available in a test area at the minimum, to foster the development of innovative use-cases employing the APIs. When such APIs apply to the banking and financial systems, such networks have come to be known as an Open Banking network or system.
The goal of Open Banking is to democratize banking and financial services to widen financial inclusion and foster the development of financial products by easing access and participation of secondary providers; where such *providers* are usually non-traditional financial institutions. While most proponents for an Open Banking system share this goal, the interpretation of what the Open Banking system constitutes and by inference how it is designed and implemented would differ largely due to prevailing economic, social, regulatory and infrastructural levers within the specific economies.
Therefore, Open Banking Nigeria (OBN) standard tailors to the particulars of Nigeria's payments environment. The APIs are designed to simplify and structure access to financial services on both supply and demand side, while ensuring the highest standards of consumer data protection and systems security are employed.
On this basis, the following are guiding principles of the network design:
1. **Non-regulatory:** The standard is not deemed *regulation* to participants. The intent is to promote democratic adoption and permeation of the APIs, removing legacy institutional barriers to create an ecosystem propelled by evolving business models, financial products, risk appetites, and investment capacity.
2. **Simple:** Given the terrain, the standard specifies just the essential requirements to provide functional structure, maintain security and be operable with known and easily accessible technology platforms. This is expected to promote adoption across all institutional scales, ensuring that every relevant institution has a fair opportunity to participate. The standard will continue to be refined for emerging requirements and technologies.
3. **Venture-driven:** Varying appetites for risk and opportunity are accommodated within the framework by prescribing a minimal set of *required* services for core service providers, beyond which each organization can configure offerings and enter into partnerships purely on the merit of the opportunities.
4. **Consumer-focused:** The standard should guide participants in building systems and operations with the consumers' needs as the core consideration. The network should provide transparency, security, privacy, and control to users. The end-user experience should be guided by simplistic designs, nevertheless, speed and flow are paramount.
### Rationale
The design caters to structural, procedural and data exchange requirements necessary to operate a secure and open payments system. To achieve this in the best-fit approach, the standard centers on the interface with the core financial service providers as the foundational infrastructure for the open system, allowing evolving market needs to define secondary or higher-level architectures if necessary. While these higher levels of infrastructure are not elaborated, the framework assures consistency in quality of end-user experience by prescribing guidelines for core consumer processes that are key to the Open Banking experience.
The standard also does not define or delve into commercial or contractual obligations among participant organizations. Financial institutions are encouraged to adopt open APIs, partner with organizations that promote their ambitions and adopt business operations that align with their risk models.
### Governance
Open Technology Foundation (OTF) is a not-for-profit organization comprising payments professionals representing various individual and corporate efforts to promote an Open Banking system. OTF defines, maintains and promotes Open Banking standard consisting of API specifications and accompanying security and process guidelines.
OTF currently comprises corporate membership such as Commercial Banks, Fintechs and consulting firms as well as individual members typically those operating professionally within the payments and financial services sector. The foundation is open to anyone with a stake, interest or contribution to the financial and payments services sector of the economy. The trustees of the foundation conduct the day to day operations while non-trustee members lend their expertise and resources to the objectives of the foundation. Members of the foundation work alongside the governing committee of the foundation to define and refine the Open Banking standards. All member institutions have equal rights.
Nigeria Open Banking standard is published on the Open Banking Nigeria (OBN) portal: [*https://openbanking.ng*](https://openbanking.ng/). The portal serves as the information hub for all updates and developments with the standard. It does not currently actively participate in the interconnection of participants in the Open Banking system. However, the portal serves as a certification center for institutions to self-test their Open Banking APIs and publish their offerings after successfully going through the test stages. The primary objective is the definition and promotion of a standard to address a fundamental payment ecosystem need.
### Participants and Roles
Given the Open Banking proposition, any organization that provides financial and payment services within the country is a potential participant. This includes but is not limited to:
1. Regulators such as the Central Bank of Nigeria (CBN)
2. Licensed Interbank Switching companies
3. Payment Card Scheme companies
4. Commercial, Merchant, Mortgage, Microfinance, Digital-only and Payment Service Banks operating at any scale;
5. Mobile Money Operators
6. Financial Technology Providers
7. Bill and Utility Payment Aggregators
8. Tertiary finance institutions such as Mutual Funds, Investment Houses, Insurance brokers.
Logically, the framework categorizes all participants into the following roles, where a participant could play one or more roles depending on their services and offerings:
1. **Account Providers (AP)** – being the core of the Open Banking network, these organizations provide access to consumer funds which could be traditional consumer accounts held by Commercial Banks and Microfinance Institutions or non-traditional, such as Mobile Money Operators, Credit Unions, Prepaid Card Systems, etc. In the broad sense, institutions operating at this level are able to maintain the financial balances of individual customers and provide data and payment services to other institutions within the Open Banking network.
2. **Third-Party Providers (TPP)** – are technology and financial services companies that occupy the "service-side" of the Open Banking system and typically integrate with open APIs exposed by APs while providing services to end-users directly or through other similar organizations in the value chain.
3. **Platform Providers (PP)** – while this role is not currently set out within this framework, there is a very high likelihood of the emergence of entities that perform an aggregation function, therefore, making it worthy of mention in this material. These entities would aggregate connections to multiple APs and act as a single point of integration for other Financial and Payment Service Providers (FPSPs) that wish to participate in the Open Banking framework. For the purpose of this document, the term Third-Party Providers includes such providers except otherwise exclusively stated.
### Systems Architecture
The design places the AP role at the foundation of the Open Banking network. A logical architecture is shown in figure 1.0 below. Open APIs provide the rails for TPPs to access AP platforms and services. Open APIs consist of CRUD (Create, Read, Update, Delete) functions that are grouped into the following four categories based on similarities in the API functions: Registration, Meta Directory, Data-Inquiry (Open Data), and Payments.
1. **Registration APIs** provide the framework for Identity management, verification, and permission controls to access other APIs.
2. **Meta Directory APIs** provide a collection of cacheable, less volatile information essential for payloads sent/received within the network.
3. **Data-Inquiry (or Open Data) APIs** contain a collection of financial data objects for which TPPs can be given access to read general financial institution information.
4. **Payment APIs** contain APIs that return customer information and permit payment operations such as basic debit and credit operations as well as other specialized payment flows. The baseline criteria for APIs in this collection is the fact that these APIs involve the movement of accountholder funds or access to individual consumer data.
TPPs connect directly to these APIs essentially bridging the supply-side of financial service and then provide platforms to connect the demand side: users and consumers. The architecture at the TPP level and further onward is not covered by the Open Banking specifications. The Open Banking network is expected to complement other payment networks. Participants' connections to NIBSS Instant Pay, switching networks, service, and utility provider payment aggregators serve to enrich the Open Banking offering, creating an ecosystem of boundless connectivity and robust possibilities.
### Value Proposition
As is typical of an open system, innovation is expected to create new propositions that derive benefits for all stakeholders. We expect to see propositions along these lines:
1. **Financial Inclusion:** Open APIs will allow FPSPs to build inclusive products, typically over digital channels, for the financially excluded and most vulnerable members of the society. Thinning out the financial exclusion indices within any economy is expected to have multi-faceted effects to improve the socioeconomic well-being of its citizens.
2. **Data:** Seamless access to financial data across the entire banking ecosystem means primary data such as average income and consumption expenditure over a period can be applied to estimate the creditworthiness of non-salary earners for non-collateral loans. Secondary data such as user spend analysis opens a new horizon of data services to deduce consumer choices and provide more streamlined offerings. Artificial Intelligence and Big data management opportunities are likely to emerge from these new horizons.
3. **Access:** Consumers are expected to experience broader means and channels of access to finances which would vary in degree of ease and sophistication. We expect to see emerging products and technologies in communication, identity verification, and authentication, access and consent management take center stage in expanding the net of inclusion. While closed financial payments systems provide little incentives for participants to undertake these investments independently, Open Banking players can bring this to fruition by leveraging services (in whole or part) provided by other participants within an open ecosystem.
4. **Provider Selection:** Customers will have access to a network of providers to select the best fit for their needs with little to no barriers to mobility. This increased competition should drive prices of primary financial services downwards and ultimately, secondary and more sophisticated financial services such as data-based offerings, asset refinancing, cross-selling, etc. will serve as differentiating factors.
5. **Transacting:** The above scenarios are further entrenched by the innate mobility of funds within an open system where customers can allocate or move funds easily to their preferred providers. Payments or the activity of making a payment is expected to devolve into less of an activity and more contextualized to the particulars of a transaction. For example, instead of paying with a mobile phone solution, a car could just as well pay for the fuel it receives from the vendor.
6. **Security:** Open Banking simplifies integrating to legacy financial institutions by providing a single framework with standard security features and processes, apt for financial-grade services. This ensures a uniform implementation by APs, reducing the risks to both APs and TPPs if each party alternatively had to develop their own standards.
### Summary
The OBN standard and specifications enable APs to create secure and structured interfaces for accessing customer financial data and initiating payments against customer accounts. APs can apply this document as a guide for designing and setting up Open Banking infrastructure, as well as best practice procedures to operate the services.
TPPs can simply adopt the specifications provided here to gain access to the network and connect to each AP, subject to overarching business interests among participants. TPPs are expected to also adopt the guidelines in operating their solutions and services within the network. With a paramount focus on consumer privacy and data protection, strict requirements are stipulated on how such providers should utilize and protect customer financial data, maintain consumer control and provide transparent and competitive financial services.
Subsequent sections of this standard detail the specifications covering data exchange mechanics, a robust security framework, operational guidelines and customer experience requirements that collectively make up this standard.
### FAQs
* Is Open Banking a payment platform?
*In the current design for Nigeria, OBN portal or Open Banking* *is NOT a payment platform. OBN is simply a standard* *which embodies the framework* *required of institutions intending to participate alongside other certified financial institutions in the open banking network. FPSPs will have to connect to the institution endpoints directly and not through* *OBN portal.*
* Will there be an Open Banking Enterprise Service Bus (ESB)?
*We expect that aggregators will provide such ESBs to manage connections to financial institutions and from their clients. However, OBN will not require or provide this infrastructure as part of the current standard.*
* Who owns Open Banking Nigeria Standard?
*Open Banking Nigeria standard is open to the entire Nigerian financial industry and is not under any ownership. Open Technology Foundation is* *presently the custodian of the standard.*
* How do I know if my bank participates in Open Banking?
*OBN maintains a registry of certified participant APs which are listed on the OBN portal at* [*https://aps.openbankingng.com*](https://aps.openbankingng.com/)*. If your bank is listed on OBN portal, they would also provide a list of platforms and solutions that they have allowed to connect.*
* Is Open Banking regulated by the government or any other payments system regulators?
*Currently, no.*
* Who will continue to maintain and govern Open Banking standards?
*Open Technology Foundation trustees are currently responsible for maintaining the Open Banking standards for the foreseeable future. This function may be passed on in future if the move is determined to foster the payments and financial services sector.*
# Overview
The operational guidelines prescribe the levels of service required of APs and TPPs in the Open Banking system. These guidelines are essential to a consistent user experience across the Open Banking network. The operational imperatives are:
1. To promote high service levels across the network
2. To create a positive experience with customers, building trust by maintaining consistency in Open Banking processes across all platforms, offerings and providers.
3. To ensure that APs and TPPs support open APIs with standard operational procedures that minimizes the need for exceptional intervention into every-day processes.
# Service Management
### Communication Management
The focal point for communication requirements in this standard is in the area of incident management and resolution. APs are expected to provide or prescribe secure real-time communication platforms for first level incident responders within their organizations and respective TPPs for incident notification, investigation and resolution. The platform *is required to* accommodate text, voice and video conferencing modes of communication to support various scenarios. Broadcast groups can be set up to communicate to all TPPs which an AP supports.
Note that separate from this channel, formal channels (such as help and support systems or ticketing solutions) should still be used for incident reporting and management and would be the true source of data for SLA assessment. Emails are not a sufficient method of incident management within the OBN standard.
### Configuration Management
Detailed inventory of Open Banking systems configuration items must be kept in accordance with ITIL (version 4 or the most recent) standards for posterity, ease of impact assessment and general management. At the minimum, the inventory must be electronically searchable.\
As a guide, the architecture of the configuration or inventory database may be designed as follows:
1. Logical listing of system types i.e. systems containing identical software and configuration elements are essentially the same "type"
2. Definition of configuration items and per system type. This could be coded with a serial or preferably a pseudo name or anagram that allows the configuration item to be deduced easily.
3. Physical listing of systems and specifications of each configuration item per system type
4. Diagramming tool that reads off the inventory to typify the architecture of the systems showing connections and dependencies.
5. An assessment tool that can be trained to diagnose the health status of the configuration items and provide visual aids to possible points of failure in the system.
### Service Monitoring
Monitoring is a required operational service for APs and should be performed at the API level. APs may internally monitor hardware, hypervisor, operating system, application environment metrics for good measure.
Open APIs are to be monitored at the functional level. Performance metrics as defined in this document should be collected contiguously for all processing done by the APIs. These metrics should be persisted to permanent storage by the minute so useful information is available for investigation if there is a crash or interruption.
APs are required to implement monitoring processes that alert (visually or otherwise) first-level support personnel to suspect and critical level occurrences as defined in OBN performance levels. Incident management procedures should be triggered with such alerts.
### Incident Management
Open banking incidents are classified as:
1. **Functional:** involving or affecting the good path of a single operation or function. Where such a function is critical to a major offering of the system for instance, a problem with the authentication procedure which effectively bars everyone from accessing the system, then the classification graduates to systemic. Function-level incidents are likely to be spotted via declining metrics such as % successful calls, average total processing time and API availability or while investigating user complaints.
2. **Performance:** incidents relating to performance may be gradual or acute. In general, they are characterized by degradation of service levels and may be spotted with metrics such as long avg. processing times, fluctuating % success rates without any corresponding changes in volume and fluctuating availability.
3. **Systemic:** cover issues that prevent one or all installations or instances of the Open Banking API infrastructure from offering service, a degradation of service levels across a majority of the functions, or unavailability of a major system function.
A general procedure to incidents:
1. Determine the scope of the incident and impact i.e. functional, performance or systemic. Notify/Alert TPPs relying on services via the recommended communication channel.
2. Assess if a fail-over is necessary, if the failover system is ready and will not exhibit the same symptoms.
3. Consider workarounds. The objective is to restore service in a timely manner. However, workarounds should not impair the integrity of the system or result in loss of data.
4. Determine if a failover is less costly than the loss experienced from the incident. Cost may be determined by estimating the disruption due to the failover process (in terms of time or transaction loss) weighed against the criticality of the service(s) to be restored.
5. Make go/no-go decision and commence investigation into root cause and resolution. Follow documented procedure if a "go" decision is made.
APs are required to adhere to the following guidelines:
1. Provide personnel to monitor and support Open Banking API infrastructure on 24x7 basis. Contacts for such personnel should be made available to TPPs within SLA documentation.
2. Ensure personnel providing support to the infrastructure have access to detailed documentation of Open Banking systems, functions and internal dependencies. This documentation should be maintained synchronously with any system changes.
3. Design and review on a quarterly basis an incident management and response manual indicating failover and failback steps to be undertaken for a critical incident. The manual should be appendix-ed with lessons learnt from previous critical incidents.
4. An incident logging and ticket management platform is not required in strict sense but is very much encouraged.
The following generic performance levels form the minimum standard for Open Banking systems:
| Metric | Operational | Suspect | Critical |
| ------------------------------- | ----------- | -------- | -------- |
| Availability | >98% | >=95% | <95% |
| Avg. API Total. Processing Time | <3 secs | <=7 secs | >7 secs |
| Success Rate | >95% | >=90% | <90% |
| Incident-type | Response SLA | Resolution | Fail-over |
| ------------- | ------------ | ---------- | ----------- |
| Functional | 2 hours | 4 hours | +30 minutes |
| Performance | 30 minutes | 2 hours | +30 minutes |
| Systemic | 15 minutes | 30 minutes | +30 minutes |
### Problem Management
This refers to management of issues known to be recurring or which are not resolved within the window of the SLAs per type of incident. A problem register is required of APs to indicate:
1. The date/time a problem was discovered
2. Characteristics of the problem such as system symptoms and impact.
3. Any interim measures that have been applied to manage the problem while keeping the system operational
4. Plans for a resolution or description of the intended solution
5. Deployment date – date the change is applied to the systems to implement the identified solution.
6. Review and problem resolution date – problem finally closed after reviewing the effects of the change. Should also indicate steps and outcomes of review.
This problem register should be available to Regulators, Auditors, Risk and Control teams within the organization and provided in reports to TPPs according to schedule stipulated in the Reporting section of this document.
### Change Management
Changes, and notices thereof are recommended to be managed on a monthly basis. This implies that APs should collate their change requirements and plan the changes for the next month except in cases where the change is expected to resolve a critical incident or problem.
All changes (either preempted or responsive) should be reported in sufficient detail as specified by the reporting guidelines. Changes should also be accompanied with notifications to any organizations within the Open Banking systems that could be affected by the change:
1. 24 hours before the intended change
2. 1 hour before the intended change
3. Immediately the change has been completed and services have been confirmed restored or thirty minutes after the change should have been completed but has been prolonged or the change failed.
4. At the point of commencing a change rollback.
5. When services have been restored.
The framework expects an initial change report with content as specified in the reporting section, subsequent notices can simply reference the initial report and a final updated report provided after the change activity.
For ease, organizations are advised to employ mechanisms and systems that help identify individuals to be notified and create templates for reports and notifications with placeholders for the variables.
### Business Continuity Planning
APs and TPPs should provide sufficient redundancies and fail-safe/recovery procedures to match their SLAs. The gaps and level of risk in providing redundancy can be estimated by considering:
1. Possibility of in-flight data loss and if such losses occur, the viability of recovery procedures to maintain integrity.
2. If replication is employed to maintain redundant processing infrastructure,
* the replication time-lag between OLTP systems and on the average, the nature and quantity of data processed in that time frame; and
* the replication time-lag from OLTP to OLAP systems.
APs are required to maintain a Business Continuity Plan that includes quarterly failover exercises and review of processes. Plans should indicate the architecture of the OLTP and OLAP infrastructure, physical and logical redundancies, replication intervals, processes for failover and fail-back, responsible individuals and/or roles and trigger events
As indicated, the threshold defined for failover and fail-back procedures is 30 minutes of downtime. While the OBN standard does not specify technologies or architectures employed for redundancy, the procedures adopted by APs should fall within this stipulation. In future, Business Continuity Plans may be assessed by qualified professionals as complaint with this standard.
# Front-Office
### Dispute Resolution
Disputes over financial transactions may be in any direction and can be raised by consumers, APs or TPPs. Disputes could also be related to debit, credit or billing transactions i.e. inter-participant settlement arrangements.
The following guidelines are to be following by APs and TPPs in treating disputes:
1. Neither party should recommend that the customer raises a claim with the counterpart except in cases where it is clear that the claim does not involve the Open Banking framework operations.
2. APs and TPPs are encouraged to employ relevant management software to handle logging, tracking and resolving dispute claims along with internal and external communications management in the course of the dispute.
3. Mechanisms for raising claims *must* be conspicuously available to customers via any of the digital channels or interfaces supported by the TPP or AP.
4. Consumer disputes are expected to be resolved conclusively within 2 working days, but may take up to 5 working days during exceptional cases. The threshold for such should be less than 20% of all cases. Inter-participant disputes should be resolved within 5 working days.
5. APs and TPPs should investigate to identify any discrepancies in their systems. This may require both the AP and TPP to exchange transaction records, at the minimum indicating the unique references for the transactions, the date/time and the transaction amount. Both organizations should be open to this and preferably proactively develop channels or interfaces for transparent exchanges.
6. If both organizations have dissenting views regarding the true state of the transaction(s), independent assessors may be employed to audit both organization's systems to confirm that each system has operated correctly and in accordance with OBN standard regarding message integrity, fault recovery, data storage and retention.
7. Issues involving irrecoverable financial losses should be treated according to the recommendations in the *Liability and Financial Loss* section of this document.
8. Where both organizations are still in disagreement, this issue may be escalated to an arbitrator who is also a regulator in the payments system and jurisdiction covers both entities. Escalations should detail efforts made by both organizations to reconcile the transactions and the independent assessment reports. Customers should however be reimbursed by the TPP for clear cases where their funds were deducted without service before the stipulated 5 working days' elapse. If the AP is found to be in breach eventually, the AP shall refund the TPP the amount paid to the customer including interest equal to the MPR prorated across the number of days after reimbursement of the consumer.
### Consumer Claims
1. A customer dispute if determined to be invalid, should be responded by the receiving participant should detail a guiding explanation of what transpired (or possibly what was done wrong) as well as a transcript of the user's actions that may have led to the inequity.
2. If a claim is deemed valid, the participant shall take ownership of the case and make reasonable efforts to rectify the inequity within the prescribed time frame for resolving such cases, even where dependent on third-party institutions.
3. If the claim involves the performance of service in response to consumer payments and such service can still be performed, the participant *may* inquire of the customer if they prefer the performance of the service as a resolution before proceeding. Otherwise, the customer's funds should be completely refunded including any fees taken for the service.
4. In the case of a transaction that is determined to be a duplication of an original transaction, the participant is to confirm that the duplication is not caused by faults in the channel solution. If corresponding value has not been provided for the duplicate transaction, the participant is to refund the customer within the stipulated time frame. If value has been provided and the duplication is clearly as a result of the consumer's error and not a fault within the provider's channel, the participant reserves the right to decline the claim but may also provide any assistance to improve the customer's experience at their own discretion.
5. Where a dispute is raised with respect to a credit to a consumer's account, the TPP should confirm that the claim relates to a valid transaction and immediately lien the amount on the recipient's account (if the credit was made through Open Banking channels). A letter should be sent to the recipient's AP which the AP should forward electronically to the recipient to confirm that they are in agreement of the funds being reversed. If agreed, the funds and accompanying fees should be revered to the claimant. If the recipient is not in agreement, the TPP should:
1. Request a civil meeting between both consumers to agree on a resolution
2. Where this fails, initiate an expedited hearing with a judge of competent jurisdiction where both parties should be accompanied by legal counsel, although a hearing could be conducted in absence of the customer (recipient or initiator).
3. If the claimant is found to be in the wrong, the case may be treated according to the terms and conditions of service provided by the TPP or AP.
4. If the recipient is found to be in the wrong, the recipient shall repatriate the funds which will be effected by the AP against the recipient's account, along with any other terms provided in the conditions of service by the provider.
5. The complete process should not exceed 10 working days in addition to the initial 5 days prescribed for typical cases.
### Fraud
The following guidelines should be adopted by APs and TPPs when a fraud is reported or discovered, regarding a consumer's account accessed through a TPP solution:
1. An occurrence or suspicion of fraud may be reported to an AP or TPP by consumers. Whichever participant receives this notice must take ownership of the case and drive its closure within the stipulated time frame. Both APs and TPPs must provide channels for customers to lodge such complaints.
2. Fraud reporting channels or links *must* be made conspicuously available to customers over any channels or platforms operated by the TPP. APs *must* also provide channels directly to the customer.
3. Both participants are encouraged to maintain a fraud desk and apply software management systems for proactive detection, interception and management of fraud cases.
4. Users must be provided at least two (2) alternative self-service channels or processes in addition to the primary access channel offered by TPPs for instantly deactivating or un-linking their AP credentials if they suspect compromise. Stricter measures should be employed to re-link these credentials if the customer uses these options, such as a call to the service desk to verify identity and understand the reason for the user's action before the AP account can be added afresh. This is separate from a service where the TPP allows the user to enable / disable transactions against their profile as a feature within the TPP's application.
5. The party to whom a fraud is reported (known as the receiving party) is required to communicate to the consumer the expected time frame for investigations, and keep the consumer appraised of any significant developments that occur in the course of the investigation.
6. Consumers are required to notify the participant of their choice (AP or TPP) of the fraud by at most 60 days from the time of occurrence of the incident. While participants are encouraged to employ best efforts to resolve such cases, no guarantees can be provided if this time frame elapses before a complaint is made.
7. The receiving participant of the consumer's complaint must also lodge a formal record of the case with the counterpart participant within 48 hours of receiving the complaint.
8. The TPP's access to the AP account of the user should immediately be suspended by the receiving party until investigations are concluded. The receiving institution will assume liability for any fraudulent activity performed with this access exceeding one hour from the time the customer lodged the complaint. Participants may guide the customers to use self-service alternatives and confirm effect immediately.
9. A fraud case is required to be resolved within **28 working days** of being lodged by the consumer.
10. Resolution in this context means that a plausible explanation has been given to the consumer regarding the whereabouts of the funds inquired of, how the funds were accessed and a transcript of activity against their account. If the consumer is deemed culpable for the missing funds by way of compromise of their access channel, then no reimbursement is required to the consumer.
11. Any reimbursements to be made must be done within the time frame specified in 9 above.
12. If a sufficient conclusion is not reached within the stipulated time due to lack of cooperation of the counterpart or the case remains irresolute even with the evidence provided, the receiving party is required to escalate the case to the regulator, in this case the CBN, within 48 hours and continue to advocate for the customer until the case is resolved. A copy of this complaint should be lodged with OBN at .
13. The consumer's AP account access may be restored once the root cause has been determined and deemed unlikely to reoccur.
14. APs and TPPs must operate in good faith towards one another in communicating to the customer and must not communicate sensitive network or participant information or act in any way to degrade or diminish the credibility of the counterpart.
15. Where a breach is discovered that could prove systemic, the TPP or AP is required to investigate the extent of the issue and commence emergency procedures to rectify this lapse within 48 hours of the discovery. Appropriate containment procedures must however be employed immediately to ensure that the issue does not compromise other user accounts or participants.
### Liability Rules
Organizations that participate within the OBN network are NOT absolved from liability where there are preventable occurrences of financial loss to customers. The following are known scenarios where a participant will be deemed liable to cover any financial losses to the counterpart participant or consumer:
1. Where it is proven or clear that the participant did not observe best practices in handling the consumer information or platform operations leading to compromise or where a breach occurs as a result of weaknesses in their infrastructure or processes that has been exploited by fraudulent persons without any carelessness with security credentials on the part of the consumer.
2. If an AP or TPP fails in their responsibilities to provide sufficient and immutable evidence of the activity that resulted in the funds movement of a customer, then that party *will* be liable and required to reimburse the customer except the counterpart is able to provide sufficiently conclusive evidence of the activity against the account, as originating from the consumer's legitimate access channel.
# Back-Office
### Accounting and Settlement
No specific commercial structures are recommended between APs and TPPs. As a guide, the following practices may be adopted:
1. Operations involving movement of funds within the AP's domain could be recorded at the account level of the TPP involved, possibly sub-accounting based on the API function in-use.
2. Metrics used for billing should be definitively agreed and indicated in the contract of service between APs and TPPs. Bills may be collected in real-time, near-time, on a scheduled basis daily or on a daily-totals basis after reconciliation. The schedule should also be indicated in the same contract. Any billings from APs should be accompanied with reports providing summary and detailed information for the bill preferably along with the bill, but at most within a business day of passing the bill. The definition of these reports or any related systems integration requirements for exchanging these reports are beyond the scope of this standard.
3. Billing may be effected by direct debits to the TPPs accounts with the AP or initiated by the TPP to the AP over their preferred transfer channels. The preference should also be stated clearly in the underlying contract.
4. APs may support separate principal and fee-collection accounts for TPPs to ease accounting and revenue recognition.
Without switching licenses, TPPs are not expected to engage directly in interbank services, and by inference, settlement. A TPP may debit or credit a consumer's account within an AP domain, but if a corresponding impact is to be performed within another AP domain, the TPP must employ interbank switching channels to facilitate the transfer.
As such the following guidelines apply within this framework for inter-participant settlement:
1. For Debit and Credit operations, the AP may apply real-time impact to the TPP's accounts domicile with the AP along with any fees agreed for the operation. If the model chosen is not a prefunded TPP account, the AP should maintain a distinct suspense account per TPP where all impacts and recorded and the net value posted against the TPP's operational account on the agreed schedule with accompanying reports according to the reporting schedule.
2. For interbank transactions, settlement will be performed by the interbank switching scheme. The TPP will be recognized as an agent or channel of the AP and any instructions by the TPP over the interbank network should cite the AP from which funds were pulled as the settlement entity. Interbank settlement will thus apply the same schema and procedure as the provisions governing the switching license. Any settlements between the AP and TPP for this use-case can be handled as a typical debit operation. In the case of settlement errors or disputes, the TPP must provide records of the payments made through this mechanism for the AP's use.
### Reporting
APs should provide monthly reports to TPPs indicating:
1. API Performance levels for the month and previous FY months or previous quarter. Metrics may be grouped into the four API categories: Registration, Meta, Data and Payment APIs.
2. Statistics of incidents across the three categories, SLA compliance and aggregate impact in downtime or loss of service if any occurred during the period.
3. Number and category of Fraud and Disputes with accompanying SLA performance
4. Excerpts of the problem register indicating new, existing and resolved problems.
5. Changes made, reason (in sufficient detail), timing and estimated impact.
6. Changes scheduled for the next month and potential impact.
In addition, APs are required to provide the following to account holders that have subscribed to one or more TPPs:
1. Optional notification of a TPP accessing the consumer's account(s) in real-time or near-time via email, SMS or in-app prompts. (Similar to a notice of internet banking login)
2. A transcript of each TPP's activities against the consumer's account up to the last 180 days. Transcript in this sense should show each major operation carried out, the interface or channel signature, the time and status of each major operation showing request and response pairs, and any associated financial movements.
3. Appropriate distinctions in account statement records of TPP related activity versus core business activities.
### Fees
OBN does not prescribe fees or commercial settlements of any nature among participants. Any fees are to be negotiated and agreed between each pair of APs and TPPs.
### Reconciliation
No reconciliation format is defined within this release of the OBN standard. To reduce the need for lengthy reconciliation efforts, participants are advised to implement event-triggered billing systems where the bills are easily traceable to the activity performed, and also accounting by APs for TPPs should be treated on a transactional level rather than batch process that may prove challenging to reconcile.
# Operations-Readiness Checklist
| Category | Requirement | Required | Recommended |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ----------- |
| **Communication** | - Design communication plan for all incident types. Include plan in service level agreements
- Implement real-time interface for incident management with Audio, Video and Text capabilities.
- Implement ticket management systems / processes
- Onboard partners on TMS and communications platforms.
| AP |
|
| **Monitoring** | - Design KPI gathering and storage architecture
- Implement performance and availability gathering mechanisms, plug into reporting module, publish over APIs if feasible.
- Setup visual aids and triggers for alerts
| AP | TPP |
| **Incident Management** | - Document incident management plan with clear operational processes to meet SLAs, align with communication plan.
- Keep an open register of incidents and categorize per type, log each occurrence.
- Track and report incident and resolution occurrences
- Escalate recurring incidents to problem management
- Keep lessons learnt and knowledge base repositories
| AP | TPP |
| **Business Continuity Plan** | - Document business continuity plans, detailing processes, responsibilities and redundancies provided. Ensure detailed steps are enumerated and design to meet SLAs.
- Schedule review and failover activities for the year
- Track results and problems
| AP, TPP |
|
| **Problem Management** | - Inaugurate a problem register detailing issue type, date, symptoms, stop-gap, resolution plan and dates
| AP | TPP |
| **Change Management** | - Institute change register maintenance and change management process and owned by appointed Change Advisory Board members
- Ensure change notification schedules are implemented as recommended and employ technology tools where possible.
| AP |
|
| **Reporting** | - Design reporting templates and systems, and plug-in to data sources. Note recommended report data
- Ensure reports are segmented per participant
- Automate reporting where possible.
| AP |
|
| **Accounting & Financial Management** | - Capture billing arrangements within business/service contracts.
- Design and document accounting procedures to provide clarity between operations, accounting and business management personnel.
- Create process for updating this process with new products/services
| AP | TPP |
| **Reconciliation** | |
|
|
| **Settlement** | - Adhere to guidelines regarding switching operations.
- Ensure inter-participant settlement operations are clearly defined to amounts, timing, defaults, overdrafts etc.
| AP, TPP |
|
| **Dispute Resolution** | - Implement systems to track & maintain required SLA
- Implement consumer interfaces for raising and communicating updates on disputes
- Design and operationalize inter-participant dispute management processes.
- Train operational personnel for Open Banking related disputes and procedure handbook to guide action.
| AP |
|
| **Fraud and Liabilities** | - Design and operationalize fraud management processes
- Establish legal and business framework for treating liabilities
- Implement controls to ensure compliance at all levels
| AP |
|
# Overview
The customer experience guidelines are perhaps the strictest of OBN requirements to TPPs. Note that these guidelines are to be followed by both intermediary and end-user providers. The objectives of the consumer experience guidelines are to:
1. Define a minimum engagement framework or process for the consumer's interaction with Open Banking enabled systems
2. Define critical elements of the consumer journey that are paramount to creating the desirable consumer experience, consistent across platforms
3. Engender consumer trust with the system
Elements of the consumer journey relevant to Open Banking commence at enrollment, accessing financial data, payments initiation, and strong authentication.
### Design Principles
1. Simplicity: Open Banking functionality must be simple, unambiguous and direct. The language used to communicate prompts should not be overly legal or technical.
2. Transparency: Customers should be acutely in-tune with each process they are undertaking, knowing the objective, where they started and wherein the process they are. It would also be helpful to inform, to a reasonable extent, what it would take to complete the process and what to expect as the outcome.
3. Parity of Experience: Open banking TPPs should present largely consistent prompts (in number and order) especially where related to core processes such as registration, account access, consent, payment initiation, and authentication.
4. Control: The customer should always be in and be given a sense of control over every process. While consent and access may be given initially without much thought or full understanding of the implications, the customer should be able to unceremoniously revoke such consent and access at all times. Any scheduled activities should include reasonable reminders of such activity if the customer wishes not to continue. Subject to specific use-case exemptions, customers should be notified of and subscribe to any new services or process especially those with impact on their account funds.
### Consumer Journey
A customer's Open Banking journey commences with requesting access, through the TPP interface, to their account information within a specified AP domain. The AP is expected to seek consent from the user through any established channels, a process which is referred to within this section as Strong Authentication.
Due to the varying nature of consent channels, it is possible in certain cases that the request for access from the TPP to the AP will not complete synchronously. Therefore, TPPs should factor the waiting time into the user experience and implement APIs that check the consent status after the initial request period.
Following authentication of the user by the AP and authorization of the TPP's access to the user account information, the TPP is required to present an account access handle (e.g. a widget, button, link, or text indicator) within the consumer experience interface designating access to the consumers' accounts within the Apps domain.
The user's subsequent interactions with this handle should be limited to managing permissions to the AP's account. Most other operations within the TPP domain are expected to "pass-through" by interacting with this handle as if directly accessing the consumer's account.
### Registration
User experience during registration is largely determined by the underlying channel technology and process each pair of TPP and AP have agreed and implemented. This standard requires the process to be consistent although differences in channel technologies and approach may result in slight variations.
At the setup stage, TPPs are expected to register their applications within AP domains using the relevant Registration APIs or via manual setup depending on which the AP is able to provide. TPPs may request as many permissions as they may require within the matrix of object permissions allowed in the APIs. APs however, reserves the right to approve, reject and revoke permissions as they deem fit driven by business and other related considerations. Concluding this process, a registration record should indicate functions in which the TPP is limited to performing within the AP domain. APs are encouraged to increase the responsibility and obligations of TPPs within contracts synonymously with the extent of access requested within the AP domain to deter access to unnecessary features that do not fall within the business services of the TPP or might be purely prospective at the time of setup. Registration records can be easily updated to reflect new, dropped or revoked permissions as contracting evolves subject to agreed terms.
To onboard a customer, a registration record is also expected to be lodged with the AP by the TPP including the minimum customer information as set out by the mandatory fields of the relevant registration API, but distinctly indicating the linked Account Number. A TPP cannot lodge more than one registration record with the same account number. This process starts with the customer visiting the TPP interface, selecting an AP and indicating their credentials within the AP's domain. The Authentication mechanism set up between with TPP and AP would determine the experience and mode of completion of this process. Guidelines for authentication are provided in the next section. An active registration record will be created on behalf of the customer to be managed exclusively by the TPP once authentication has been performed. However, no permissions have been assigned to this record until explicit assignments are initiated by the customer which will require *authorization*.
### Authentication
Authentication within this context provides a mechanism for users to verify their identities to the APs to permit linking the indicated account within the requesting TPP's domain. APs are required to provide authentication mechanisms in whichever form they support and available technology permits, but must conform in principle and architecture to the following requirements for authentication:
1. **Authentication must happen over pre-authorized channels** – this means that the user must have priory authorized or consented to receiving sensitive account information over this medium and also designated certain levels of authority to electronic communication received by the AP over such channels e.g. if email is one such channel, an email indemnity must have been authorized by the customer prior to that channel used for consent in line with the regulations of the Central Bank of Nigeria. Other channels include SMS, USSD, Mobile Banking App and Internet banking.
2. **User endpoint *****should***** be verified prior to use for authentication –** emails, phone numbers or other user endpoints must be verified using control information such as OTP verification prior to being used as a platform for Open Banking consent. To illustrate, if a user has signed up to mobile banking either via the Smart Phone App or USSD, it is assumed that the user's mobile number is a verified endpoint. Similar verification should be performed for the user's email address although the requirement for email is not as strict.
Also popularly known as Second Factor Authentication or 2FA, strong authentication adopts these principles combined with eliciting confirmation of the customer's identity. The API documentation lists particulars that require such strong authentication. APs will initiate strong authentication via agreed/ implemented channels whenever access is requested to an AP account by a customer. Strong authentication mechanisms include:
1. **Decoupled authentication** – where the AP employs known channels to initiate an "out-of-bound" request for the consumer's confirmation of the TPP access request. Channels include:
1. Mobile Banking App – the customer can be prompted with a listing of pending TPP permission requests and may be given control to enable/disable each TPP as required. This imbibes the strong authentication mechanism since the Mobile app sign-up process incorporates pre-enrolment, endpoint verification, and the customer would have to log in to access the menu.
2. Internet Banking App – same as mobile
3. USSD Banking – In this case, the customer would be directed within the TPP interface to visit the bank USSD menu, navigate to an "Open Banking" option and follow the prompts to approve their app request. APs may also implement USSD push interactions to the customer's registered mobile number to prompt for approval. In either case, verification information such as a mobile PIN is required to complete the process.
4. SMS – may only be used to inform the customer of the need to navigate to some other banking channel to complete the authentication.
5. Email – may be used for authorization if the customer has consented to email indemnity specifically for TPP Open Banking access.
2. **AP Redirects -** over smart channels, and where supported by both the TPP and AP, TPPs may redirect to the authentication page/prompt of the AP for the customer to provide login credentials. This redirect may occur over browser to browser, app to browser, browser to app or In-app. The basic requirement is that customers are presented with identifying marks such as logo, colors of their APs with which they are familiar and help build trust. A simple way to achieve this is to scrape the internet or mobile banking login pages. In addition, the login requirements to authenticate the customer must not exceed or be different from their typical banking access requirements on the specific channel.
Once customers are authenticated; the AP issues an access token to the TPP to be used exclusively by that TPP when accessing the customer's account. The user's registration with the AP is also marked as active at this point. Note that multiple accounts within an AP domain require a repeat of the Registration and Authentication process to map each account to a separate handle within the TPP application.
### Authorization
Within the context of open banking, authorization is the process by which customers consent to TPPs accessing all or parts of their personal and financial records of authenticated AP account. TPP's are required to operate according to the following guidelines:
1. Each account handle within the TPP's application should provide mechanisms for customers to immediately enable or revoke permissions to different particulars of their AP accounts.
2. Each change in the user's selection should be proceeded with the generation of a new OAuth token to capture the change in scope, especially where the change is a reduction in the user's permissions list. Optionally, the AP may provide APIs for the TPP to also revoke the permissions at the AP's end before generating a new token.
3. When prompting users for consent on the TPP's application, account particulars may be grouped for ease of presentation. For instance, all required particulars to facilitate a business function maybe group. However, upon selection, the TPP should provide sufficient information in the confirmation screen that captures (or makes available) the details of the particulars involved.
4. Account particulars should map directly to user scopes detailed in Section 2.4 of this document. Scopes should be presented in friendly and easily understandable language that embodies the object, action, initiator (user or auto) and periodicity.
5. TPP's are also required to send out notifications (via email, SMS or other agreed channels) to customers indicating any changes to permissions requested against their AP accounts for the user's keepsake.
Following the user's request via the TPP application for certain scope permissions against their AP accounts, the user's AP is required to provide two (2) channels at the minimum by which the user can view, consent, decline or revoke permission requests. For instance, an AP could provide a page listing pending and approved TPP authorization requests within the Mobile or Internet Banking platforms.\
If consent is given by the user for specific scope permissions, the records of such consent should be recorded along with a timestamp, an audit record capturing a transcript of the change in permissions scope and the point of initiation. Revocations should also be captured with similar detail. Consented scopes are updated within the AP's API-framework and subsequent token requests by the TPP on behalf of the user will include these scopes in the permitted scopes list along with embedding the permission into the generated access token. The AP may provide additional services to notify the TPP of the approved scopes so the TPP can proactively enable those functions within the user's profile instead of waiting for the next sign-on event.\
APs should never honor requests for functions or particulars on behalf of a user where the consent for the scope has not been given by the user, or the period for which the consent was granted has expired. An appropriate decline response should be provided in such cases. If there is a timeout during an authorization request exchange, the TPP has the sole responsibility to repeat the function until a valid confirmation is received.
# Authorization
Accountholder authorizing scope requests on AP channel
\
Consumer Experience Checklist
| SN | Category | Requirement | Required | |
| -- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | - |
| 1 | Design | - Design mockup of application flows.
- Confirm through sampling and surveys that users resonate with OBN design principles: simple, transparent, consistent experience, and user in control.
|
TPP
| |
| 2 | Consent Framework | - Ensure users have at least two (2) non-primary self-service channels for revoking consent
- Ensure that application interfaces allow users to manage TPP permissions (authorization)
|
AP, TPP
| |
| 3 | Registration | - Implement registration data-stores and audit trails
- Ensure policies for required retention are implemented
| TPP | |
| 4 | Authentication | - Agree on authentication methods supported considering user experience, level of users' sophistication, available technologies.
- Implement supported authentication flows
| AP, TPP | |
| 5 | Authorization | - Ensure users have recommended access channels for managing permissions
- Design permission prompts and management screens according to consent framework and user experience guidelines
|
AP, TPP
| |
\
\
\
# Mobile App Interface Guidelines
### Adding an AP account on the TPP Interface
### Account-holder authentication ***options*** on AP channel
### Adding an AP account on the TPP Interface
# Overview
\
The security framework within this standard cover:
1. Entity and User Identification and Verification
2. Permission Management
3. Data Ownership
4. Data Storage and Retention
5. Consumer Consent
6. Network or IP Transport Layer Security
7. Endpoint Security
8. Message Level Security
These elements are grouped into sections covering Consumer Security, Data Exchange Security and Data Management Security.
# Security-Readiness Checklist
| Category | Requirement | Required | Recommended |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------- |
| Data Ownership | - Determine which data types are exposed by APIs and categorize accordingly.
- Ensure non-essential consumer profile data is not released.
- Ensure contracts restrict the usage of consumer data to agreed scenarios.
- Confirm TPP access is restricted to functions in their permissions matrix
- Design groupings for object permissions (if required) e.g. Lender's Profile may contain permissions for statements and balances only, Trader's profile may include payments and balances, but restrict statements.
- Ensure compliance with NDPR, 2019
| AP, TPP |
|
| Consent Framework | - Create the consent management data structure including Authentication, Authorizations and audit trail structures.
- Ensure consumer data access is based on authorized features as well as TPP permissions
- Design and Implement strong authentication channels according to desired flows and risk polices. At least one channel should be implemented.
- Implement user-channel options for controlling TPP access.
- Implement transcript reporting
| AP, TPP |
|
| General Requirements | - Obtain ISO 9001 and 27001 certifications or equivalent accreditations.
| AP | TPP |
| Transport Security | - Implement OBN general data security requirements including network DMZ, SSL certificates and secure file share channels.
| AP, TPP |
|
| Endpoint Security | | AP, TPP |
|
| Data Storage | - Create OLTP and OLAP processing systems with synchronization process and redundancies
- Audit database structures to ensure compliance with ownership framework
- Ensure non-essential and verbose information are limited especially in OLTP systems to reduce processing overhead.
- Configure retention policies for transactional, consent, audit and configuration records in line with indicated standards.
| AP, TPP |
|
| Data Security | - Comply with the data security guidelines enumerated above.
| AP, TPP |
|
\
# Data Management and Exchange
The following guidelines may be employed organizations intending to participate in the Open Banking system, however, these represent strict requirements for APs. Organizations should:
1. Be ISO 9001 and 27001 certified or obtain equivalent or similar Quality and Information Security management accreditation.
2. Place Open Banking APIs in a distinct network DMZ from other systems within the provider's network.
3. Implement system level firewalls to manage the exchange of information between Open Banking APIs and internal systems; limited to very specific functions allowed.
4. Implement requisite controls against denial of service attacks, malware, viruses and other digital threats.
5. Likewise restrict any exchanges from internal systems to the Open Banking API-hosted servers to the required minimum and essential personnel only.
6. All communication to and from Open Banking APIs must be over an SSL TLS v1.2 connections with mutual certificate authentication at each end of the line. Organizations that prefer to host certificates on a proxy device such as a firewall or network load balancer must ensure that internal communication between the proxy system and the system hosting the APIs is secure.
7. File exchanges must occur over SFTP; never emails even if password protected. APs are required to provide such infrastructure or leverage cloud solutions.
### Network or Transport Layer Security
For Open Banking APIs, ASN X.509 certificates provide transport level security to API calls with TLS 1.2 two-way mutual SSL authentication.
TPPs who expect to connect with APs will be required to submit a Certificate Signing Request to the AP via SFTP at the minimum or over any secure portal provided. The CSR is signed by the AP and the signed certificate returned to the TPP to be loaded securely into a keystore.
All API exchanges between the TPP and AP require mutual authentication before data can be exchanged. Details on generating a CSR, signing a CSR, importing a signed Certificate and enabling mutual authentication on the client and server sides are provided with the API specifications.
### Endpoint Security
APs are required to maintain identifiers such as the public and private IP addresses and application meta-data of connected TPPs. This information should be used to create endpoint signatures of the respective TPPs. Operating within the Open Banking network requires APs to carry out endpoint-level assessment to the tune that credentials of the TPP application and users may only be permitted when used from an endpoint matching the compiled TPP signature.
If a data breach occurs at the TPP, this prevents any pilfered data from being used publicly or from another domain to access information relating to the TPP within the AP domain. The algorithm for building endpoint signatures is provided in the API specifications.
### Message Level Security
Refer to message and field level security implementations in the *Messaging Standards* section.
### Data Security
APs must secure data storage environments by ensuring:
1. Physical measures are put in place to prevent unauthorized access to the servers or operating environments of Open Banking systems
2. Certificates, keys and any security related credentials are conveyed with the strictest security measures, handled only by authorized personnel within the security, risk and/or IT control teams and securely dispose of any copies created once the credential has been applied, stored or outdated.
3. Sensitive credentials are stored securely with the use of a HSM (hardware or software), Keystore, Truststore, Certificate Management System or other security apparatus that manages credential inventory and provides measures to prevent unauthorized access.
4. Any file-system stores for security credentials are encrypted and password-protected
5. Passwords are not stored in clear, placed in files or directly in code.
6. File system copies are restricted, and any files copied into the systems are screened with up-to-date antivirus and intrusion prevention software.
7. Database and system files are rendered unreadable if copied out of the primary operating systems except through an application with requisite security credentials.
8. Open banking application and database servers are placed within different operating system environments and different DMZs
9. Access to database and application servers (at the operating system level) is provisioned to separate groups of individuals.
10. User access at the application level is segmented according to roles. The following roles should be defined as required: monitor, view, audit, configuration, admin, superadmin.
11. Application roles are defined separate from user roles to access the database.
12. Database access must be segmented by user roles similar to segmentation at the application level. In addition, user profile data, financial data and transactional data must be further segmented, and access provisioned on an as-needs basis.
13. Access to user profile and financial data is restricted at the database level to users with administrative level access.
14. All activity, including that of the administrators is audited (at application and database levels) and audit records remain inaccessible to all but the designated audit/control personnel. Audit records are also retained for a minimum of 90 days
15. Sensitive user profile and financial data must be stored in encrypted format in the database.
16. Database users may not view such sensitive data directly except application users provisioned with security clearance to decrypt such data.
### Data Storage
The definition of physical database architecture is not within the of scope of the OBN standard. The following requirements relate to logical organization of data processing systems for optimal operations:
1. **Data Storage Layout:** In principle, the storage design should cater to OLTP and OLAP data types, and both systems should be kept separate at the application and hardware levels. Real-time processing would naturally occur within the OLTP environment and asynchronously transitioned to the OLAP environment almost immediately.
2. **Data Types:** Organizations may store only data which they own as defined within the ownership framework. API request and response pairs may be stored with the exception of account statements or similar data that may prove too cumbersome and not provide any operational benefit if stored.
3. **Retention:** In general, data owned by each party should be stored and made available for investigation for a minimum of 180 days. Specifically,
1. Transactional data with financial impact is required to be stored for **10 years** according to requirements of the regulators.
2. User consent information and profile information must be stored for at least **90 days but no longer than 180 days** after the user is deactivated on the system.
3. Audit Trail records should be kept by all providers for a minimum of **1 year from the time of the change.**
4. Systems configuration data does not fall within this category, but as good practice may be backed up regularly or according to the schedule of planned changes and the inventory maintained for rollback purposes.
# Securing Consumer Information
TPPs and APs *must* comply with the provisions of Nigeria Data Protection Regulation, 2019 administered by the NITDA including the statutory assessment and reporting requirements. If there are any discrepancies between this framework and the prescriptions of the NDPR, those of the NDPR supersede and should be adopted by the participant. Similarly, in the case of any overlaps in the standards, the strictest standard should be adhered to by the participant.
### Data Ownership
As data could potentially be transmitted across multiple organizations in the Open Banking system it is necessary to define guidelines regarding how the data is accessed and used. The objective is to assure consumers of the security and privacy of their information to engender trust. The following types of data are considered in this framework.
#### Consumer Profile Information
This includes personal data such as date of birth, name, email address, phone number or any other piece of information that can be used to identify or qualify a user on the network. This data ultimately belongs to the consumer and should not be used in any way the consumer has not given consent. However, APs and TPPs act as custodians of this data and ownership in this sense should be seen as stewardship. The owner of this data is the entity to which the consumer has provided the data directly. In most cases, this starts with APs. In the course of data exchange, a TPP could become privy to information initially provided to the AP. Such data cannot be used as primary data by the TPP unless explicitly confirmed by the customer. For instance, in the course of retrieving statement data, a user's date of birth is returned to a TPP who previously did not have this information. The TPP can only use the date of birth in birthday greetings, age estimation etc. after providing the information to the customer to 1) confirm that this is their date of birth 2) consent to enlisting it within the application. This process is not applicable to processes of credential transfers where the customer consents to permitting a provider copy or clone their credentials from other providers. However, the credentials to be copied must be explicitly enumerated for the consumer's consent.
#### Consumer Financial Data
Details such as account number, account balance, BVN, and account statements fall within this category. Within these guidelines, a TPP may retrieve this data from APs of the consumer but is not permitted to store or utilize as primary data subsequently. For the avoidance of doubt, the duration of storage should not exceed the user's session time within the TPP's environment such that once a session is concluded, the information is expunged. This data may be analyzed by TPPs on a per-user basis and the results of such analysis stored as long as such results do not contain contiguous sets of primary data or user activity. System initiated requests for data, for instance, checking the user's balance on a regular basis, should be explicitly consented to as well.
#### Consumer Transaction Data
Transactional data in this context refers to actions performed within the TPP domain that may or may not be of financial consequence against the consumers' funds within an AP's domain. Such data is available to the TPP to utilize and manipulate within the context of their operations. Note that if such activity is recorded in the AP's domain such as a debit or credit to the account, the record of data held by the AP falls within the custody of the AP and is subsequently categorized as Consumer Financial Data.
It should be noted that data such as service and operational charges levied against customers by their APs are under the explicit ownership of the AP and may not be used for any analysis independently, called out or highlighted by the TPP. Such data may only be displayed as part of a standard transaction history listing if the feature is supported.
### Consumer Consent Framework
The thrust of the consent framework is to provide a governing structure covering types of access that require consent, how consent is obtained and recorded. All consumer profile and financial data represent information for which consent must be sought before accessing.
The following guidelines should be followed in requesting, obtaining and recording consent by TPPs and APs:
1. Consent should be explicitly requested.
1. It should state the elements of data the consumer would be giving the TPP access to
2. The prompt for consent should indicate the periodicity of the access where applicable
3. It should also state what the data would be used for and permit the customer to select functions or services for which they wish to subscribe/unsubscribe within the context of the data access requested.
4. No pre-selections should be done by the application. The user must actively perform an action to indicate consent.
5. The option to NOT proceed or deny consent must be given and stand out as a clear choice.
2. Consent should not be hidden within elaborate and verbose text such as contractual terms. It should be called out, legible, unambiguous and data objects presented in a list with familiar terminology.
3. Consent for compound data such as statement information, by inference is taken as consent to access the sub-elements contained within. However, the consent prompt should indicate the intended use and remain within those confines.
4. Consent should be recorded for the lifetime of the access and for audit purposes, 180 days afterwards.
5. Records should indicate the time at which consent was given and the details of permissions granted especially where selections are available for the consumer to opt in or out.
TPPs and APs must also comply with all of the provisions within Section 8 of the NDPR 2019 regarding data consent.
# References
| \[RFC6749] | Hardt, D., Ed. " The OAuth 2.0 Authorization Framework", RFC 6749, 10.17487/RFC6749, October 2012, |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\