Enable Banking Changelog | June
This month brought a formal Artificial Intelligence Policy that keeps AI out of the API and end-user data, several improvements to our developer documentation, and the usual round of integration updates across Europe.
Significant Changes and Updates
Our Artificial Intelligence Policy
As AI adoption accelerates across financial services, we've codified where AI does and doesn't sit inside Enable Banking. Our new Artificial Intelligence Policy formalises what has always been true of our approach: AI does not run inside the Enable Banking API, and it does not process any end-user data, including the account information, transaction data, or payments that flow through our services on behalf of end users.
For anyone building on our infrastructure, that means account access, transaction retrieval, consent handling, or payment initiation are not routed through an AI or ML model. End-user data reaches the ASPSPs and returns to your application through the same deterministic paths it always has.
AI is used strictly as an internal tool to improve our operational efficiency. That use is governed by explicit principles set out in the policy: data privacy and security in line with GDPR and the EU AI Act, transparency, fairness, and human oversight for anything consequential.
Our AI policy ensures we can harness the efficiency gains of AI while continuing to protect the privacy and interests of our customers, partners, and employees. If you are interested in knowing more about how we manage information security, please refer to our information security policy.
Documentation Updates
FAQ clarifying the re-authorisation
Added a new FAQ entry clarifying the re-authorisation process for expired account information sessions. New sessions generate unique session and account IDs. The new FAQ details how to use the identification_hash or raw account details (IBAN/BBAN/CPAN) to reliably match the same accounts across different sessions
See more enablebanking.com/docs/faq.
Extended psu_type Field Description
The documentation for the psu_type field used in the StartAuthorizationRequest and CreatePaymentRequest models has been significantly expanded to provide clearer guidance and prevent common authorisation issues. Previously, the documentation briefly stated "PSU type for which consent is created for," which led to API clients omitting the field and encountering authorisation errors.
The updated description now includes the following key details:
Impact on Authorisation Flows: The documentation now clarifies that the psu_type affects how authorisation is performed at the ASPSP, such as determining whether a personal or business login page is presented to the user.
Risks of Mismatch: A mismatch between the provided psu_type and the user's actual account type can result in authorisation failures or the inability to see expected accounts.
Best Practices for API Clients: Because the default value depends on the specific connector being used, it is highly recommended that applications always provide this value to ensure consistent behaviour.
End-User Prompting: If the client application cannot determine the psu_type on its own, the documentation now explicitly advises requesting the desired type directly from the end user (PSU).
Gruppo BCC Iccrea
Added market documentation for Gruppo BCC Iccrea, Italy's main cooperative banking group centred on Iccrea Banca. Because authentication method availability varies by BCC and by customer agreement, this documentation covers the details developers need to guide users through authorisation reliably. PSUs must select their specific BCC (Banche di Credito Cooperativo), and each bank can support up to four different authentication methods
See the full market documentation for Gruppo BCC Iccrea.
Integration Updates
New Integrations
We’ve added support for the following institutions:
Aareal Bank (DE)
BfW - Bank für Wohnungswirtschaft (DE)
BGL BNP Paribas (LU)
Credit Agricole Indosuez (FR, IT, LU)
Deutsche Bank (NL, PL)
Finductive (MT)
Raiffeisenbank Altmühl-Jura (DE)
Snappi (GR)
Swan (FR)
VR VerbundBank (DE)
And released new integrations for the following institutions:
ABN AMRO (NL) – Migrated single SEPA payments to Payment Initiation API v2
Caixa Geral de Depósitos (PT, FR) – Migrated to SIBS V4 API
ICA Banken (SE) – Migrated to the new API (v2) supporting decoupled authentication
UniCredit Bank Austria (AT) – Released new personal and business integrations
Extended Integrations
The following integrations have been extended:
Bank Norwegian (DE, DK, ES, FI, NO, SE) – Improved PSU header handling
CartaBCC (IT) – Added card account support
Credit Agricole (IT) – Added card accounts support
Lunar (DK, NO, SE) – Added payment initiation (PIS) support
SEB (SE) – Added card accounts support
Spar Nord Bank (DK) – Added as a brand under Nykredit Bank
Targobank (DE) – Added transactions download support
Fixed and Improved Integrations
We’ve rolled out reliability and performance improvements across multiple institutions, including:
Allianz Bank Financial Advisors (IT)
Atruvia-supported banks (DE)
Bank of Cyprus (CY)
Bank-Verlag group banks (DE)
BAWAG (AT)
Belfius (BE)
Bigbank (EE, LT, LV)
BNP Paribas (FR, PL)
Citadele (EE, LT, LV)
Comdirect (DE)
Credito Emiliano (IT)
De Volksbank (NL)
Djurslands Bank (DK)
Eika-supported banks (NO)
Erste Bank (AT, HU)
Hello Bank (FR)
HPB (HR)
HSBC (BE, ES, FR, IE, IT, LU, MT, NL, PL)
HYPO OOE (AT)
Íslandsbanki (IS)
Jyske Bank (DK)
Komerční Banka (CZ)
Landsbankinn (IS)
Mano Bank (LT)
MBH Bank (HU)
Mediobanca Premier (IT)
National Bank of Greece (GR)
NLB (SI)
Norisbank (DE)
OLB Bank (DE)
Partners Banka (CZ)
Piraeus Bank (GR)
Raiffeisen (CZ)
Raiffeisen Landesbank Suedtirol (IT)
Santander Totta (PT)
Shine (FR)
Skandia (SE)
Sydbank (DK)
Integrations Removed
The following integrations have been removed:
Aktia (FI) – Contingency API connector removed
Cajasur Banco (ES) – Merged into Kutxabank
Spar Nord Bank (DK) – Merged into Nykredit Bank
Sparkasse Neuburg-Rain (DE) – Branch closed down
Ya Bank (NO) – Merged into Resurs Bank
For a comprehensive list of integration changes, click here.
As always, if you have any questions, feel free to reach out to us at support.api@enablebanking.com.
Explore more:
CCD2 expands the regulatory perimeter for consumer credit significantly, and raises the bar on how creditworthiness assessments must be conducted and documented. This FAQ covers the questions we hear most often, from which lenders are affected and what BNPL providers need to do, to how open banking data supports compliant affordability assessments and what good data infrastructure looks like in practice.