PSD2 open-banking API infrastructure in Finland: SCA and SEPA instant settlement

The second Payment Services Directive (PSD2) turned the bank account into an interface: credit institutions must give regulated third parties access to payment accounts, and payers must authenticate strongly. In parallel, SEPA Instant Credit Transfers (SCT Inst) have moved from an optional service to core euro-area infrastructure under the Instant Payments Regulation (EU) 2024/886.

This article describes the technical boundary between those two layers: which data is exchanged during Strong Customer Authentication (SCA), how an authorised payment initiation passes through the API, and how an instant transfer settles in central bank or prefunded money within ten seconds. The perspective is Finnish; the mechanisms are pan-European.

Regulatory framework

The framework has three layers:

• Directive (EU) 2015/2366 (PSD2) defines payment initiation services (PIS) and account information services (AIS), and the obligation to apply strong customer authentication (Art. 97).
• Commission Delegated Regulation (EU) 2018/389, the Regulatory Technical Standards (RTS) on SCA and common and secure communication (CSC), sets the technical authentication requirements, the exemptions, and the communication rules between account servicers (ASPSPs) and third-party providers (TPPs). It has applied since 14 September 2019 and was amended by Delegated Regulation (EU) 2022/2360.
• National transposition: Finland transposed the Directive mainly through amendments to the Payment Services Act (290/2010) and the Payment Institutions Act (297/2010), in force from 13 January 2018. The competent authority is the Finnish Financial Supervisory Authority (FIN-FSA).

For instant payments, the key sources are the SEPA Regulation (EU) 260/2012, its amendment by the Instant Payments Regulation (EU) 2024/886, and the European Payments Council (EPC) SCT Inst and Verification of Payee (VoP) rulebooks.

SCA data exchange parameters

Authentication elements

SCA requires at least two independent elements from three categories: knowledge (e.g. a PIN), possession (e.g. a registered mobile device or card) and inherence (e.g. a fingerprint). Independence means the breach of one element must not compromise the reliability of the others (RTS Art. 9). Where elements are used on a multi-purpose device such as a smartphone, the device must provide separated secure execution environments.

Authentication code requirements

RTS Article 4 sets the following parameters for the code produced by authentication:

• no information about the elements can be derived from the code, and a new code cannot be generated from knowledge of previous ones
• a maximum of five consecutive failed attempts, after which the action is temporarily or permanently blocked
• a maximum of five minutes of inactivity after authentication before the session ends
• the process does not reveal which element was incorrect

Dynamic linking

For remote payment transactions the code must be specific to the amount and the payee (RTS Art. 5). The payer must be shown both during authentication, and any change to either invalidates the code. For batch payments, the code is linked to the total amount and all payees. At API level this means the instructedAmount and creditorAccount fields must be frozen before SCA starts, and the TPP must create a new initiation if they change.

Exemptions

The RTS allows exemptions from SCA. Applying an exemption is always the decision of the payer's PSP (the ASPSP).

TRA thresholds (RTS Annex) depend on the PSP's quarterly fraud rate:

Common and secure communication (CSC)

Identifying parties with eIDAS certificates

RTS Article 34 requires PSPs to identify each other using qualified eIDAS certificates. In practice the TPP presents a QWAC (Qualified Website Authentication Certificate) at the transport layer for mutual TLS, and may sign application-level messages with a QSealC (Qualified Electronic Seal Certificate). The certificate carries the authorisation number issued by the national supervisor and the PSD2 roles: PSP_AS, PSP_PI, PSP_AI and PSP_IC.

Dedicated interface and fallback

An ASPSP may offer access through its customer interface or a dedicated interface. The dedicated interface must match the customer channel in availability and performance, with statistics published quarterly (Art. 32). Unless the national supervisor has granted an exemption, the ASPSP must maintain a fallback mechanism (Art. 33).

SCA approaches at the interface

The most widely referenced European API standard is the Berlin Group NextGenPSD2 XS2A Framework. Finnish bank implementations vary: some follow the Berlin Group model, others proprietary or Nordic variants. The common SCA approaches are:

• Redirect: the TPP sends the user to the bank's own authentication environment and back (TPP-Redirect-URI). The most common approach in Finland.
• Decoupled: authentication takes place in the bank's mobile app, separately from the TPP interface; the TPP polls for status.
• Embedded: credentials pass through the TPP interface. Rare, for security reasons.
• OAuth2: often used as a pre-step to redirect or as the authorisation mechanism.

Typical data exchange parameters

Example account information consent body (Berlin Group style):

POST /v1/consents
X-Request-ID: 6f1c2a9e-3b7d-4e1a-9c55-2d8f0b7a41e2
PSU-IP-Address: 192.0.2.10
TPP-Redirect-URI: https://tpp.example/cb

{
  "access": {
    "accounts":     [{ "iban": "FI2112345600000785" }],
    "balances":     [{ "iban": "FI2112345600000785" }],
    "transactions": [{ "iban": "FI2112345600000785" }]
  },
  "recurringIndicator": true,
  "validUntil": "2027-04-05",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}

Without the user actively requesting it, an AISP may access data up to four times in 24 hours unless otherwise agreed (RTS Art. 36(5)). The value frequencyPerDay: 4 reflects that limit.

The Finnish authentication landscape

In Finland, strong electronic identification is governed by the Act on Strong Electronic Identification and Electronic Trust Services (617/2009). Bank credentials and the mobile certificate (mobiilivarmenne) serve as identification means within the Finnish Trust Network, supervised by Traficom.

Architecturally, it is important to separate two use cases that often share the same user experience:

• Identity verification for a third-party service (Finnish Trust Network, Act 617/2009).
• Payment authorisation or account access in the bank's own environment (PSD2 SCA, Regulation 2018/389), where dynamic linking applies to the transaction.

Finnish banks have largely moved SCA into their own mobile apps (possession plus PIN or biometrics), making redirect and decoupled flows the prevailing patterns in practice.

SEPA Instant Credit Transfers (SCT Inst)

The EPC SCT Inst scheme launched in November 2017. The Instant Payments Regulation (EU) 2024/886 made instant transfers mandatory: euro-area PSPs had to be able to receive instant transfers from 9 January 2025, and to send them and offer Verification of Payee (VoP) from 9 October 2025. As a euro-area member, Finland is subject to these deadlines.

The EPC rulebook's earlier scheme-level maximum amount (€100,000 from 2020) has been removed to align with the Regulation. Check the current rulebook version before implementation.

Real-time settlement mechanics

Message flow

1. The payer authorises the payment with SCA (in the bank channel or via a PISP). The payer's PSP checks funds, takes the VoP result into account and reserves the amount.
2. The payer's PSP sends a timestamped pacs.008 to the clearing and settlement mechanism (CSM).
3. The CSM validates the message and forwards it to the payee's PSP.
4. The payee's PSP checks the account and responds with a pacs.002 (accepted or rejected).
5. On a positive response the CSM settles the transaction and confirms to both parties. The payee's PSP credits the funds immediately.
6. In the PSD2 API, the status moves, for example, from ACTC to ACSC or ACCC.

Settlement mechanisms

• TIPS (TARGET Instant Payment Settlement): the Eurosystem service, live since 2018. Settlement takes place in central bank money on participants' dedicated cash accounts (DCAs), funded from T2. Settlement is final and irrevocable once booked.
• RT1 (EBA CLEARING): a private pan-European system, live since 2017. Participants prefund their positions in central bank money in T2, and the system settles transactions against those positions.

Under the Eurosystem's reachability measures, banks adhering to SCT Inst and reachable in T2 must also be reachable via TIPS, which enables euro-area-wide routing.

Liquidity management

Because instant transfers settle around the clock against prefunded balances, liquidity forecasting shifts from intraday batch work to a continuous process. Banks must size their TIPS or RT1 funding particularly for weekends and holidays, when liquidity transfers from the RTGS system are more constrained.

Returns and recalls

A rejected transaction (RJCT) never settles. A recall of a settled transaction (camt.056) is possible within the rulebook's time limit, for example for a duplicate or fraudulent payment, but the payee's PSP is not obliged to return funds without grounds. Returns use pacs.004; negative answers use camt.029.

Architecture considerations

• Idempotency: use X-Request-ID and the end-to-end identifier to prevent duplicate initiations after timeouts.
• State machines: model scaStatus and transactionStatus as separate state machines; an instant transfer can reach its final state in seconds, while a standard SEPA transfer may remain at ACTC for longer.
• Polling vs. notifications: many ASPSPs support only status polling; size polling frequency according to the interface's terms of use.
• Reconciliation: use camt.054 notifications and camt.053 statements to reconcile real-time and booked states.
• Continuous operations: 24/7 settlement also requires round-the-clock monitoring, on-call and fraud operations.
• Certificate lifecycle: automate QWAC and QSealC renewal and monitor validity and revocation status.

The European Commission's 2023 proposals for a PSD3 Directive and a Payment Services Regulation (PSR) are likely to change interface requirements and SCA practices. Check the current stage of the legislative process against up-to-date sources.

References

1. Directive (EU) 2015/2366 on payment services in the internal market (PSD2).
2. Commission Delegated Regulation (EU) 2018/389 (RTS on strong customer authentication and common and secure open standards of communication).
3. Commission Delegated Regulation (EU) 2022/2360 (amending 2018/389; 180-day account information exemption).
4. Regulation (EU) 2024/886 on instant credit transfers in euro (Instant Payments Regulation).
5. Regulation (EU) No 260/2012 (SEPA Regulation).
6. Finnish Payment Services Act (290/2010) and Payment Institutions Act (297/2010).
7. Finnish Act on Strong Electronic Identification and Electronic Trust Services (617/2009).
8. European Payments Council: SEPA Instant Credit Transfer Scheme Rulebook; Verification of Payee Scheme Rulebook.
9. The Berlin Group: NextGenPSD2 XS2A Framework, Implementation Guidelines.
10. European Central Bank: TARGET Instant Payment Settlement (TIPS) documentation.

This publication is a general informational overview and does not constitute legal advice. Regulation and scheme rulebooks are updated periodically; verify current versions against primary sources.