The EU’s Second Payment Directive (PSD2) requires banks to grant qualified third parties automated access to customer transaction accounts, covering both retail and corporate customers1.
September 14, 2019 is the deadline
Most in our business—at least those of us working within the EU—are familiar with the final September 14 PSD2 Regulatory Technical Standards (RTS) compliance deadline. By this date, banks must be ready to support open banking and all that it entails, particularly security, and secure common communications standards. By March 14, 2019, banks must have their dedicated interface (aka open APIs) ready for testing by account information service providers (AISPs) and payment initiation service providers (PISPs).
These two 2019 deadlines mean the European payments industry—which is significantly expanded under PSD2—is still organizing, controlling, and leading activities that ensure compliance with the regulations to support open banking through APIs. If you need support to meet the deadlines, let’s work together to define a path that will put you not only in compliance with the directive, but will help your business use PSD2 requirements creatively to expand your market capabilities. Softjourn has deep experience in developing and coding APIs, including implementing security best practices to help protect your customers’ data.
What Softjourn can do for you
We can find creative solutions for your toughest challenges leveraging our expertise and experience in Open Banking implementation. Usually, the scope of our work includes:
Services Analysis
At this level we:
- Define vision, business requirements, user requirements, constraints, current state, and risks. The step is aimed at understanding business processes and goals for providing APIs, services provided and APIs coverage of services. The step will include holding elicitation interviews and performing document analysis.
- Identify user classes. Based on the information analyzed during the previous step, we would be able to identify user classes of the APIs and derive their needs and expectations. This will include holding elicitation interviews and conducting focus groups with each user class representatives (this might involve developers and subject matter experts).
- Document results. The output document will contain business requirements statement, a list of services with the description, and a list of user classes with an overview of their needs and expectations.
API analysis
Here we:
- Identify current API features. This will include a detailed analysis of the API documentation, writing down the list of available features and testing them for feasibility and completeness.
- Analyze APIs features of similar organizations, perform analysis of similar products available on the market (based on the services and user classes identified previously), create a list of features provided.
- Conduct comparison analysis of the client and APIs of similar organizations, Identify features that are not available in the client’s API and might bring value to end users (based on services, user classes and competitors analysis).
- Identify and specify use cases. Based on the services analysis, we will derive possible use cases from the needs of each user class identified. Each use case will describe user requirements and quality expectations. This will require conducting focus groups and brainstorm sessions with each user class representatives (developers, subject matter experts)
- Run use cases to identify gaps in the API. It will include step by step simulation of each use case described in the previous step. All results and observations will be documented.
- Analyze the API for PSD2/PSD3 compliance, verify current API in accordance with the requirements and limitations of PSD2 regulations and technical standards.
- Document results. The output document will contain the analysis of current API features, a suggested list of features that can be added to the API, general conclusion, PSD2 suggestions.