WSO2 Open Banking solution [https://wso2.com/solutions/financial/open-banking/] is a purpose built solution for regulatory compliance in global regions including EU,UK [https://openbanking.wso2.com/], Australia [https://wso2.com/solutions/financial/open-banking/australia/]and new emerging countries. It helps banks to align with the regulatory needs while catering technical requirements with regulatory expertise.We have been closely working with EU/UK PSD2 compliance effort during past year and have improved the solution to cater a set of emerging specification in UK/EU for open banking as;
- OpenBanking UK [https://openbanking.atlassian.net/wiki/spaces/DZ/pages/16385802/Specifications]
- Berlin NextgenPSD2 [https://www.berlin-group.org/nextgenpsd2-downloads]
- STET [https://www.stet.eu/en/psd2/]
While we are working on supporting above three specifications from WSO2 Open Banking solution,interestingly there are some common factors which have been defined from each of the specifications while there are differences as well.This blog post is to write down the common defined points in each of these specifications.
API Endpoints that banks [ASPSPs] should expose to clients [TPPs]
Overall each of the specification defines about three main flows as below. TPPs [Third Party Provider] apps need to call each of below API endpoints in a secured manner to get bank customer [PSU] data from bank specific Open Banking solution.
- Account Information Service Endpoint - To get bank customer's account data including basic account information,balances,transactions,standing orders,products,etc.
- Payment Initiation Service Endpoint- To do real time payment as a direct account transfer which could be one time,periodic or a bulk payment
- Confirmation of Funds Service Endpoint- To check the funds availability of a bank customer's account or a credit card
API Security
Each of the specifications describe two levels of security on exposed APIs by banks.
- Transport Layer Security
To check the TPP send an API request with a valid certificate.The certificate validation includes Online Certificate Status Protocol (OCSP) checks & Certified Revocation Lists (CRL) checks.
- Application Layer Security
To check the TPP has obtained the correct role [AISP/PISP/PIISP] to access the API.For example:If a TPP with the role of AISP [Accounts Information Service Provider] tries to access a Payment API endpoint from the bank,it has to fail from bank.To achieve that bank side need to read the certificate sent by TPP API request and find the role attribute value and validate it.
OAuth2 and OpenID Connect support
With PSD2/Open Banking the high level scenario is the TPP [third party provider] app will able to access bank customer data on behalf of bank customer from the bank. OAuth2 is the best matching standard security protocol to cater this scenario with 3-legged OAuth2 flow. The grant types of Authorization code, client credentials and refresh are been used with OpenID Connect support for bank customer authentication.
Request body/headers signature verification
There's optional requirement set by specifications to validate the request body and header to avoid man in the middle attacks.The common approach which is describing in each of the specification is to validate the signature of headers count.
Strong Customer Authentication [SCA]
TPPs will get bank customer's actual account data /do real time account payments after user granted the permissions to TPP on behalf of bank customer.To grant user consents,it's a must that bank customer should authenticate with bank and from PSD2,it has mandated embedding multi factor authentication which is also called as Strong Customer Authentication step into bank customer authentication flow. There are three ways of achieving SCA.
- Redirect approach
- Decoupled approach
- Embedded approach
Consent Life Cycle
From PSD2, it has mandated that prior to get access to bank customer data by TPP, the bank customer needs to provide his/her consent for the TPP. Thus the user consent management is a major feature in bank specific open banking solutions. The user consent it self has a life cycle through out the API flows for accounts and payments.For example;
- Received -The consent receipt has received for bank
- AcceptedCustomerProfile -The consent has granted by the bank customer for TPP.
- Rejected -The consent has rejected by bank customer to use by TPP
- Revoked -The consent has revoked by bank customer,thus TPP cannot use it.
- Expired -The consent has expired.
The bank hosted Open Banking solution should able to manage user consents through out above life cycle statuses with ensuring data protection mechanisms while storing and retrieving.Additionally when the TPP invoke actual accounts Get API call or actual payment settlement initiation call,the open banking solution need to validate the user given consent is in granted status,if only allow the API access.
Conclusion
The March 2019 deadline is coming soon which is for banks to expose the sandbox environment with secured Accounts/Payments endpoints to satisfy PSD2 requirements in EU/UK region. WSO2 Open Banking solution ensures providing required technical capabilities based on specification mentioned requirements and bank specific requirements in a short time.If you are a bank still looking for an Open Banking solution,please visit https://wso2.com/solutions/financial/open-banking
Data Science with R and Python is a good concept to learn. You can click here and read more about the machine learning consultant. These articles contain a lot of information which helps to solve your doubts.
ReplyDelete