...
The Strong Customer Authentication (SCA) module enables banks to authenticate the customers who are requesting to access account data via an AISP and the customers who are requesting to initiate a credit transfer via a PISP. Once authenticated, the user Consent Management module facilitates banks to obtain the customers' consent to proceed with the initiation request. In order to To improve the user experience and reduce the friction between the bank and the customer/PSU, the Transaction Risk Analysis (TRA) module identifies the scenarios where SCA is necessary and feeds that information to the adaptive authentication module. The adaptive authentication module thereby adjusts the authentication strength and enforces SCA only when it is necessary.
...
The WSO2 Open Banking Analytics component enables monitoring and recording of API-level usage activity to ensure that the API owners have full awareness of the APIs, applications, and subscriptions. It also supports business KPI dashboards with business intelligence and insights on usage trends as well as custom business insights on the account and payment flows. The decision-makers of banks can use these statistics to align the business to better suit the customer needs and ultimately increase profits. The configurable alerting module enables informing the necessary parties of abnormal behaviour, e.g., API failures, a sudden increase in the response time of APIs, and a change in the API resource access pattern.
...
Transaction Risk Analysis is a method that observes the counterparties and attributes involved in a particular transaction in order to prevent, detect and block possible fraudulent behaviour. PSD2 has additional requirements for minimizing these threats of fraudulent actions that have been on the rise with the advent of new technology. To maintain the balance between user experience and Strong Customer Authentication, some additional measures have been introduced via real-time Transaction Risk Analysis and Fraud Detection during authorization. State-of-the-art identity and access management capabilities such as adaptive authentication have made this process easy by enabling the system to adapt to changing behaviours of fraud.
...
This section explains the key concepts in open banking. For more details see Key Concepts/wiki/spaces/OB200/pages/48629460.
| Table of Content Zone | ||
|---|---|---|
| ||
PSD2PSD2 is the revised Payment Service Directive legislation administered by the European Commission and mandated in 2009. PSD2 requires Europe’s banks to give regulated third-party providers (TPPs) access to customers’ account information and payment initiation with the customers’ permission and consent. Open Banking Implementation Entity (OBIE)The Open Banking Implementation Entity was created by the UK’s Competition and Markets Authority to create software standards and industry guidelines that drive competition and innovation in consumer banking. Their responsiblities responsibilities include the following:
Open BankingOpen banking has been introduced to make banking a more competitive business. Its main goals are offering greater financial transparency, a shared chance of success for all financial service providers, and more innovative services to the consumers. The current banking practice involves the customer or merchant to maintain separate relationships with different financial institutions to achieve their financial goals. Open banking introduces a more consolidated experience to the customer by allowing banks to expose their functionality via APIs. StakeholdersPSU A PSU (Payment Service User) is a person who makes use of a payment service in the capacity of either a payer, payee, or both. PSP A Payment Services Provider (PSP) is an entity which carries out regulated payment services, including AISPs, PISPs, CBPIIs and ASPSPs. ASPSP An Account Servicing Payment Service Provider (ASPSP) is a PSP that provides and maintains a payment account for a payer. Examples of ASPSPs are banks and credit card issuers. The ASPSPs are obligated to grant access to the account and transaction data on their customers’ payment accounts through APIs. TPP A Third-Party Provider (TPP) is an authorized third-party that allows merchants to accept a wide variety of payments through a single channel/third-party application, and manage the entire transaction process from start to finish. This means the TPP is responsible for the transaction flow starting from the moment a customer inputs the credit card details to the moment the funds appear in the merchant's bank account. In this process, the bank continues to be the gatekeeper of the customer's information and requires the third-party to produce a security token in order to access the customer's bank details. A TPP can be categorized into the following types: AISP, PISP, and PIISP. The customer's bank too can offer AISP and PISP services. AISP An Account Information Service Provider (AISP) provides an aggregated view of all the accounts and past transactions that a customer has with different banks. To provide this view to the customer, the AISP should have authorization from the customer to view the corresponding transaction and balance information of all the payment accounts. The AISPs can also provide the facility to analyze the customer's spending patterns, expenses, and financial needs. Unlike a PISP, an AISP cannot transfer funds from a payment account. The following diagram depicts a generic AISP flow:
To view a live demo of the AISP flow of events, see AISP demo. PISP A Payment Initiation Service Provider (PISP) initiates credit transfers on behalf of a bank's customer. The following diagram depicts a generic PISP flow:
To view a live demo of the PISP flow of events, see PISP demo. PIISP/CBPII A Payment Instrument Issuer Service Provider (PIISP) is a PSP that verifies the coverage of a given payment amount of the PSU's account. Examples of PIISPs are the banks and credit card issuers that are obligated to verify whether the given payment amount can be covered by the PSU's account through APIs. Card-Based Payment Instrument Issuer (CBPII) is a PSP (ASPSP/TPP) that issues payment instruments based on cards. Those cards can be used to initiate a payment transaction between an ASPSP and another PSP. StandardsGDPR The General Data Protection Regulation (GDPR) is a new legal framework formalized in the European Union (EU) in 2016 and comes into effect from 28, May 2018. GDPR effectively replaces the previously used EU Data Protection Directive (DPD). Regulatory Technical Standards (RTS) The European Banking Authority (EBA) published Regulatory Technical Standards (RTS). PSD2 refers to RTS for technical guidance on authentication, authorisation, and other security aspects. RTS also defines when and how to apply SCA considering the requirements of PSD2. FAPI Financial-grade API (FAPI) is an industry-led specification of JSON data schemas, security and privacy protocols to support use cases in the financial industry and other industries that require higher security. FinTech developers can accelerate secure open banking with FAPI. It uses OAuth 2.0 and OpenID Connect (OIDC) as its base and defines additional technical requirements. ISO/IEC 27001 ISO/IEC 27001 is the internationally recognised specification for an Information Security Management System (ISMS), and it is one of the most popular standards for information security. |
...
| Available APIs | Purpose |
|---|---|
| Accounts Information API | Retrieving information pertaining to about customer accounts from banks. |
| Payments API | Processing bank's customer payments. |
| Confirmation of Funds API | Managing the funds' confirmation consents by checking and revoking statuses. |
| Event Notification APIs | To notify the TPPs of events. |
...