How to comply with PSD2 Directive and the EBA-RTS? via Electra openapi

Transcription

1 How to comply with PSD2 Directive and the EBA-RTS? via Electra openapi Gyimesi István Head of IT Development CARDINAL Kft. Presentation on Heiter Ferenc Head of Product Development 1

2 PSD2 (EU 2015/2366) and Standards of EBA-RTS Inplementation of PSD2 on in each EEA states repealing PSD1 (2007/64/EK) Banks are obliged to open gateways to their customers data to new players (TPP) using secure communication channels: Offering open APIs, Statement of Payment accounts balances, Transactional history of payment accounts, Payment order initiation & authorization in EEA (payee and/or payer). 2

3 EBA RTS scopes, date of application Strong Customer Authentication (SCA) Common and Secure Open Standards of Communication (CSCS) Transaction monitoring, real time (?) risk analysis final draft submitted to the European Commission on Still not adopted by the Commission (as of ) Applicable 18 months after its entry into force (in December 2018 at the earliest) 3

4 Evolution of payment services side by side: PSD2, RTS & Instant Payment Service Understanding the needs of our Partners based on One-on-Ones so far: Offering open API for the minimum services prescribed by the PSD2: Application of basic EBA-RTS requirements (SCA, CSC): Possible pre-consideration of development needs both of Instant Payment Service and PSD2, EBA-RTS requirements Involved developments located in Front-End Applications instead of the basic Core Systems 4

5 Intense development period ahead January 2018 MIFID II. becomes operative January 2018 PSD2 Directive adoption December 2018 Application of EBA-RTS (at the earliest) 2H 2019 Introduction of Instant Payment Service in Hungary 5

6 Solution delivered by Cardinal Electra openapi 1. Electra API Server 2. ViCA Micro Server 3. Communication Server 4. API management portal 5. Limit monitoring & management, Risk analysis 6. Sandbox 6

7 Business functions of Electra openapi (1/2) RTS Developments in separate phases of releases fulfilling the RTS requirements: Phase I.: With the below functions before : Payment accounts balance statement Transactional history of payment accounts, Payment order initiation & authorisation, Availability of amount to a card-based payment transaction ( yes or no ). 7

8 Business functions of Electra openapi (2/2) New openapis developed in Electra based on bespoke needs of Cardinal s Partners Phase II. and more: 8

9 Summary of Cardinal s solution Electra openapi Stand Alone Product, Reusing components of existing Electra Systems, Proven experience in financial services industry over the past 20 years, Deep knowledge of banking Back-End Systems, Mitigating the Risk of Integration, Implementation with or without existing Electra System, Compliance with RTS requirements, Modular setup optional elements. 9

10 Electra openapi Consists of: Programming Interface System to accomplish the Interfaces 10

11 Technology RESTful API, ISO20022, XML/JSON, YAML, OAuth2.0/OpenID Connect. Non-compliance of recent initiatives (OpenBanking, IFX, Caps) with EBA-RTS & ISO20022 Standards, Electra openapi must comply with national and EU Standards and Regulations, Built-In potential to support further APIs. 11

12 Product Lifecycle Implementation of an Easy-to-Extend System in several phases Phase one with a Go Live Date of Open API for the minimum services prescribed by the PSD2 (Payment accounts balance statement; Transactional history of payment accounts ; Payment order initiation & authorization; Availability of amount to a card-based payment transaction ( yes or no ). Application of basic EBA-RTS requirements (Development Portal, Sandbox, SCA) Further phases after New functions to different Client segments, Introduction of In-house APIs for Banks internal services. 12

13 Integration Modular setup ( LEGO cubes ) Connection to Banks Back-End Systems using the existing components of Electra System, Management of Business Data and Workflows with the components of Electra Internet Server (ISO and session messages) Fast and smooth System Implementation, Vertically and horizontally (optional) Scalable. 13

14 Architecture (Full configuration) 14

15 1. Electra API Server (EAS) Realization of business functions defined in Open API, Direct Access to the Banks Core and Back-End Systems, Deployment of the existing components & interfaces of Electra System, New queries through tested Interfaces, Connection between the EAS and external System components using WebService API. 15

16 2. ViCA Micro Server Authentication by 2 Factors defined by SCA in EBA-RTS Standards (knowledge and possession), Digital Signature of payment transactions, Management of Users Authentication of Electra System, Authentication Service can be used by different banking applications via WebService call (new function). Improvement of ViCA Application (Fingerprint Scanning). 16

17 3. Communication Server Communication between the EAS and the API Management Portal, Enhanced Security Appliance protecting Banks internal Systems and Networks by application of Protocol Break. 17

18 4. API Management Portal Suggested Solution: WSO2 System Full scale API management, Documentation Tool, API version & lifecycle management, TPP management, Full scale of Test-access (Sandbox), Providing usage analytics of API. Implementation in Banks internal HW environment, Provision of Load Balancing and Back-Up Systems, Personalised design using Banks unique and individual colors and images, Support documentation only in English. s 18

19 WSO2 19

20 5. Limit Monitoring & Management, Risk Analysis Applications of limits ordered by Article 15. of EBA-RTS to authenticate the payer (Low-value transasctions), Adjusting individual client limits defined by the Bank, Restraining the amount of payment initiations defined by Banks, Transactional Risk Analysis established in Article 16. of EBA-RTS, Assumed date of delivery: 4Q 2018 (EBA-RTS full implementation). 20

21 6. Mock Server Testing Access to 3 rd party developers, Allows the full range of responses and scenarios to be tested without having to set up and manage a complex test infrastructure, Identical funcionality to live Systems, Allows to Development Teams to run tests isolated from live Systems, Relieving live Systems and Providing safe environment of Back-End Systems 21

22 Architecture (Basic configuration) 22

23 Carte du Jour Basic components (EAS, Communication Server): obligatory ViCA: obligatory in case ViCA Application is not yet available, ViCA for 3 rd Applications (Micro Server): optional, Horizontally Scalable: optional, Limit Monitoring & Management Server: optional, 2018Q4 Risk Analysis Server: optional, 2018Q4 Functionally enriched upgraded API Packages: optional 23

24 Electra openapi Project milestones Submitting the bid for implementation by Cardinal Collection of orders from our partners Cardinal s development period UAT period Go live date 24

25 Electra openapi 25

26 Thank you for your attention! 26