Between a bank’s systems
and a new service.
FinTechAPI combines an API layer with integration tools that help make banking services available to authorised partners.
One architecture.
Several perspectives.
Bank systems execute operations and store data. The API layer defines access to services. Partners use interfaces within the scope of their permissions.
FinTechAPI is integration technology. The platform itself does not grant authorisation to provide regulated payment services.
Authorised access. Agreed interfaces. A shared standard.
What happens in between?
Choose a scenario to explore the roles of the user, partner and bank.
Data with a defined purpose.
AIS provides access to account information. This is a conceptual flow, rather than a complete technical specification.
The user grants access
The bank’s authentication process establishes the agreed scope of access.
The partner calls the API
An authorised provider makes a request using the agreed interface and permissions.
The bank provides information
Account or transaction data supports the partner’s service within the permitted scope.
From an instruction to a payment status.
PIS lets an authorised provider initiate a payment order at the user’s request.
The user chooses to pay
The partner’s application starts the payment process with the necessary information.
The bank authenticates the user
Authorisation takes place through the bank’s process for the operation.
The partner receives a status
The API provides information about the order within the bank’s supported scope.
Room to test. Before production.
A sandbox lets teams check integration scenarios using test data. Its scope and limitations should be documented.
Understand the interface
Documentation describes operations, data formats and required permissions.
Test the scenarios
Sample requests and data help test both expected behaviour and errors.
Plan the launch
Test results inform the preparation of a production integration.
Shared tools.
A common integration language.
Component availability, implementation scope and required adaptations are agreed individually.
API layer
Interfaces connecting authorised partners to bank services and systems.
Developer portal
Documentation, operation descriptions and resources for integration teams.
Test environment
A space for testing scenarios separately from production data and operations.
Management and administration
Tools supporting configuration and access control for available services.
This description presents the architecture and scope communicated for FinTechAPI. Before a project, we review the current components, their fit with your infrastructure, and the required integration and maintenance work.
Your infrastructure.
The bank stays in control.
In the established FinTechAPI model, the platform, developer portal and sandbox could be deployed within the bank’s infrastructure. Integration with core systems and internal APIs can be performed by bank specialists or an implementation team within an agreed scope.
Authentication and authorisation have different roles
The solution description uses OAuth2 and access tokens. Customer authentication is handled by the bank, for example through a redirect to online banking. SCA requirements and partner identification must be addressed in each implementation.
Security spans the whole flow
Encrypted communication, permission checks, application registration and interface protection form part of the architecture. Protocol versions, configuration and controls must be reviewed against current standards and the bank’s infrastructure.
Based on the previous FinTechAPI platform description. This does not certify the security of a new implementation.
Does it replace the bank’s core system?
The API layer integrates with existing systems and exposes agreed services. Changes in source systems depend on the bank’s architecture.
Does it provide access to every bank?
FinTechAPI is presented as banking API technology, rather than a ready-made multi-bank aggregation service operating under a shared AISP licence.
Where should we start?
With your existing architecture, expected API scope and the problem to solve. These help determine the fit of the components and the work required.
Good APIs start
with a good conversation.
Architecture, integration and changing requirements. Let’s discuss your project.