For a bank, PSD2 is the moment when systems built for years of closed operation suddenly have to open up to the world through APIs. The directive requires the bank to expose account data and payment initiation to licensed third parties, and open banking turns that from a legal duty into a real shift in architecture. For a chief digital officer, an architect or an IT director, that means one thing: PSD2 is a technology project, not just a compliance exercise.
In our experience, the hard part is not understanding the directive but translating it into secure, stable and maintainable APIs in an environment where the banking core, anti-fraud systems and regulatory demands all run at once. We do not have a public case study in this area, and we will not pretend otherwise. We do something else, and we are strong at it: we supply the people who will build it - engineers experienced in banking integrations and platform delivery, embedded in your team as team augmentation or a dedicated team.
What are PSD2 and open banking, and what do they force on a bank?
PSD2 is the EU Payment Services Directive that opens the market to new players and obliges banks to work with them. Open banking is the broader phenomenon growing out of it: the bank stops being a closed silo and becomes a provider of services through interfaces.
In practice, the directive forces several things on a bank at once:
- account access (AIS) and payment initiation (PIS) made available to third parties,
- strong customer authentication (SCA) wherever the risk calls for it,
- a secure, documented interface for third parties, aligned with an adopted standard,
- a test environment and registration so external providers can connect.
This is not a one-off change in a single system, but a new layer you have to maintain and grow alongside the rest of the bank.
How do you expose APIs for third parties (AIS/PIS)?
Two kinds of service sit at the heart of readiness. AIS (Account Information Service) lets a third party, with the customer’s consent, read account and transaction data. PIS (Payment Initiation Service) lets it initiate a payment straight from the customer’s account, with no card in between.
Building these interfaces is more than exposing an endpoint. We design them to handle real traffic from many parties at once, with a clear contract and without overloading the source systems. We wire the API layer into the banking core through stable integrations, add rate limiting and versioning, and base the whole thing on the standard the bank adopted - so each new third-party connection does not call for rebuilding the foundation.
How does strong authentication (SCA) work in the context of APIs?
Strong customer authentication (SCA) is the requirement to confirm identity with at least two independent factors: something the customer knows, something they have and something they are. In the API world, SCA is what decides whether opening the bank stays secure or becomes a door for abuse.
The challenge is to weave SCA into API flows without breaking the customer experience. We put it together from several pieces:
- redirects and tokens linking the customer’s session to the third party’s request,
- handling SCA exemptions where the regulation allows them (e.g. low amounts, trusted beneficiaries),
- binding consent to authentication, so the customer knows what they are agreeing to,
- consistency with anti-fraud systems scoring transaction risk in the background.
A well-designed SCA protects the bank and the customer without turning every operation into a test of patience.
How do you handle security and customer consent?
Opening the bank through APIs pushes the trust boundary outward, so consent management becomes its own component, not a footnote. The customer has to know who they grant access to and for how long, and be able to revoke it at any moment, while the bank records, enforces and audits that state.
We look at several layers at once here: encryption and certificates in communication with third parties, a consent registry tied to a specific data scope, a full audit trail of every access, and monitoring that catches unusual traffic patterns. Security in open banking is not a single feature but a property of the whole architecture - and we treat it that way from the project’s first line of code.
How do you design the API architecture and manage it?
The technical heart of PSD2 is the layer between the outside world and the inside of the bank. It is usually built around an API gateway and consistent management of the interface lifecycle.
We assemble this layer from parts that have to play together:
- an API gateway as the point of entry, authentication and rate limiting,
- microservices translating requests into operations in the bank’s systems,
- a developer portal with documentation and a test environment (sandbox),
- monitoring and observability, to see traffic, errors and performance in real time.
This foundation keeps APIs under control as the number of connected parties grows.
Why is open banking an opportunity, not just an obligation?
Most banks start with compliance, but stopping there wastes the potential. The same infrastructure you build for the obligation opens the way to Banking as a Service and new revenue models.
With solid, well-managed APIs, a bank can go deeper: offer services to partners through interfaces, embed payments inside third-party apps, build its own fintech products on its platform. This is the key shift in mindset - investment in APIs stops being a cost of compliance and becomes a product foundation. That is why the architecture is worth designing with that second stage in mind from the start, even when regulation forces the kick-off.
Which skills do we provide for a PSD2 project?
One profile is not enough for a project like this. We staff roles around the specific work, not “just in case”:
- solution architects who understand banking-core integrations and API patterns,
- backend developers (e.g. Java, .NET) building AIS/PIS services and SCA logic,
- DevOps / platform specialists standing up the API gateway, environments and pipelines,
- security engineers owning encryption, consent and audit.
We treat experience in platform delivery and banking integrations as a condition of entry, not a nice-to-have.
How fast can a team join a banking project?
Speed can be critical here, because regulatory deadlines do not negotiate. Our recruitment usually closes in about three weeks, stretching to two months only for non-standard requirements. As a nearshore partner from Poland we work in a close time zone, so engineers join your working rhythm, code reviews and meetings without a long ramp-up. In a banking environment we add time for security processes and access - and plan for it honestly.
How do we do it at RITS?
We do it as a nearshore partner from Poland that reinforces your team with people, not slides. In PSD2 and open banking, our role is concrete:
- we staff the roles of architects, backend, DevOps and security, matched to your stack,
- we build the API layer and integrations under your bank’s management and standards,
- we bring platform and integration experience, without claiming other people’s rollouts as our own,
- we verify skills before the start, because a bank leaves no room for guesswork.
Most often we work as team augmentation or a dedicated team, and where a closed scope is needed, as a custom software project delivered by our team.
Where do you start getting ready for PSD2 and open banking?
Start from one question: which services (AIS, PIS, SCA) and in which standard you must expose first, and how that plugs into your banking core. That answer defines the API architecture, the security requirements and the roles you need on the team. Only then is it worth deciding on an engagement model - we covered the differences in our article on IT engagement models.
Getting a bank ready for PSD2 and open banking? Let’s talk - we’ll match the engineers and the architecture that will build it with you.