What Is PSD2 Open Banking? APIs, Consent, and AI Agent Use Cases

PSD2 is the Second Payment Services Directive (Directive (EU) 2015/2366). It was adopted in 2015 and became effective across the EU in the following years, with major implementation milestones around 2018.

The core idea: banks must allow licensed third-party providers (TPPs) to access account information and initiate payments through secure interfaces—if the user consents. This is what people mean by “open banking.”

PSD2 created two key service categories:

• AIS (Account Information Services): read access to balances and transaction history.


• PIS (Payment Initiation Services): initiating payments (with safeguards).

For bookkeeping, AIS is the important one. It lets software import transactions without screen scraping and without storing your credentials.

Why PSD2 exists

PSD2 was designed to increase competition and innovation in payments while improving security. By creating regulated categories for third parties, the EU made it possible for fintechs to build products on top of bank data without requiring customers to share credentials.

For businesses, the most visible PSD2 impact is operational: bank feeds became easier to integrate, and reconciliation became less manual. For consumers, PSD2 shaped authentication standards (SCA) and how consent works.

In the Netherlands, PSD2 is part of the broader shift toward digital financial infrastructure: more API access, more security expectations, and more clarity on who is allowed to access what.

Licensing and supervision (why trust is possible)

PSD2 access is not for arbitrary apps. Third parties are typically licensed and supervised in the EU. That supervision is part of why open banking is safer than credential sharing.

For Dutch businesses, the practical takeaway is simple: prefer integrations that use PSD2-style consent flows and licensed providers. If an integration asks for your online banking credentials, it bypasses the PSD2 security model.

Open banking under PSD2 is an interaction between three roles:

• ASPSP: the bank (Account Servicing Payment Service Provider)


• TPP: the regulated third party (fintech / AISP / PISP)


• You: the account holder giving consent

A typical AIS flow looks like this:

1) You start a connection in an app (for example: bookkeeping).
2) You are redirected to your bank to authenticate with Strong Customer Authentication (SCA).
3) You grant consent for a defined scope (accounts + transactions).
4) The TPP receives access tokens and can fetch balances and transactions via API.

Important: PSD2 is designed so you do not share login credentials with the third party. Consent is explicit and revocable.

In Europe, many banks follow the Berlin Group NextGenPSD2 API standard (or compatible patterns). That standardisation is why one integration approach can work across multiple banks.

Under the hood (what’s actually happening)

Most PSD2 AIS implementations are variants of the same pattern:

• A redirect flow sends you to your bank for authentication.


• After SCA, the bank issues a consent object and the TPP receives tokens.


• The TPP calls API endpoints for accounts, balances, and transactions.

Banks differ in details (token lifetimes, pagination, error codes), which is why production systems need normalisation and retries.

A key security practice is periodic re-authentication. For AIS, many banks enforce SCA renewal roughly every 90 days. That is not a bug; it’s a deliberate control to prevent long-lived silent access.

AIS vs PIS in practice

AIS is what most bookkeeping products need. It answers “what happened?” (balances and transactions). PIS answers “make something happen” (initiate a payment).

For most businesses, mixing bookkeeping automation with payment initiation is unnecessary risk. We keep bookkeeping agents on AIS read-only access and treat payments as a separate, human-approved workflow.

Practical integration details (what breaks in production)

Even when APIs follow Berlin Group patterns, production integrations fail for predictable reasons: pagination differences, delayed transaction availability, and inconsistent counterparty fields. That’s why we build connectors with retries, idempotency (stable transaction IDs), and normalisation.

If you evaluate a PSD2 integration, ask whether they handle:

• Duplicate detection (the same transaction imported twice)


• Backfill and catch-up after downtime


• Consent expiry warnings and re-connect UX

These details decide whether “open banking” is a reliable data feed or a constant maintenance task.

With AIS, the accessible data typically includes:

• Account identifiers (IBAN) and account metadata


• Current and historical balances


• Transaction history: dates, amounts, descriptions, counterparty details (as provided by the bank)

What PSD2 does not require you to share:

• Your online banking password


• Full access to unrelated banking products

The exact fields vary by bank and API implementation, which is why robust bookkeeping systems include normalisation and fallback logic.

Field-level reality (what data looks like)

Transaction data usually includes a free-text description, which is helpful but inconsistent. Some banks include counterparty names cleanly; others include payment references that require parsing.

For bookkeeping agents, that inconsistency is normal. We treat bank descriptions as signals, not truth. The agent combines those signals with receipt evidence and vendor history. If a receipt is missing, the workflow should park the transaction instead of guessing VAT treatment.

Also note what is not present: banks don’t provide invoice PDFs. PSD2 gives the payment trail; you still need your invoice/receipt process for evidence.

Why descriptions matter (and why they’re messy)

Most categorisation systems rely on the transaction description plus counterparty fields. Those fields can be noisy (merchant codes, abbreviations, reference strings). That’s normal.

A robust AI bookkeeping agent uses descriptions as a starting point, then improves accuracy with evidence (receipts) and learned vendor patterns. If evidence is missing, the correct workflow is to flag and park—not to guess.

PSD2’s security model is built around consent and Strong Customer Authentication.

Strong Customer Authentication (SCA) typically means two independent factors (something you know, have, or are). In practice: a banking app approval plus a PIN/biometric.

Consent is user-initiated and scoped. For AIS, banks often require periodic re-authentication (commonly around 90 days) so long-lived access isn’t silently permanent.

From an engineering perspective, good PSD2-based systems also enforce:

• Read-only scopes for bookkeeping


• Secure token storage


• Audit logs for access


• Clear user controls to disconnect

If a tool asks you to share credentials, that’s not PSD2 open banking. That’s credential sharing—and it’s a red flag.

Read-only by default (for bookkeeping)

For bookkeeping and monitoring, AIS read access is sufficient. We consider payment initiation out of scope for bookkeeping agents because it increases risk.

When we integrate PSD2, we look for four safety properties:

• Clear consent screens (user knows what they grant)


• Scoped access (accounts and data types)


• Secure token storage (rotate and revoke)


• Access logs (who fetched what, when)

If any of these are missing, it becomes harder to defend the data flow under GDPR/AVG and internal security reviews.

Token renewal and the 90-day pattern

In many AIS setups, banks enforce a renewal pattern where the user re-authenticates periodically (often around 90 days). This keeps consent fresh and reduces the risk of forgotten long-lived access.

From a product perspective, this means your bookkeeping system must handle renewals gracefully: warn the user before the connection expires, provide a clear reconnect flow, and avoid silent data gaps.

PSD2 and GDPR together

PSD2 governs access to payment accounts; GDPR governs personal data. In practice, you need both: PSD2-style consent flows plus GDPR-style purpose limitation and retention controls.

A good implementation gives the user clear controls: disconnect access, see what accounts are connected, and understand what data is being imported. On the provider side, access should be logged and tokens should be revocable.

PSD2 is especially valuable for agentic AI because it turns bank data into a real-time data source. In our Fiscal Agent workflow, PSD2 enables:

• Continuous transaction import (no CSV exports)


• Vendor pattern learning (better categorisation over time)


• Faster exception handling (missing receipts are detected early)


• Quarter-to-date BTW totals that stay current

We treat PSD2 data as sensitive: we keep access read-only for bookkeeping, we minimise the fields used in prompts, and we log tool access. The agent uses the data to propose bookkeeping actions, not to move money.

Concrete agent workflows enabled by PSD2

PSD2 turns the bank feed into a trigger source. That enables workflows like:

• Real-time categorisation: classify transactions as they arrive and learn vendor patterns.


• Receipt matching: detect a transaction, then look for a receipt; if missing, route to the exception queue.


• BTW readiness: keep a running VAT position so the quarterly deadline becomes a review step (not a rebuild).


• KOR monitoring: track turnover against the €20,000 threshold and warn early.


• Anomaly detection: flag duplicates, unusual amounts, or new payees.

A simple example: if a business has 300 transactions/month and reviews exceptions weekly, they avoid the month-end backlog that causes mistakes. PSD2 is the foundation because the data arrives continuously.

VAT and evidence (why PSD2 is only step 1)

PSD2 gives you the payment trail. VAT correctness depends on the invoice/receipt trail. That’s why our agent pipeline always includes evidence handling: receipt inbox, OCR where needed, and an exception queue for missing documents.

Once evidence is linked, the agent can keep quarter-to-date BTW totals current and surface what’s missing before the filing deadline. That is the real operational win: fewer last-minute surprises.

Quarterly workflow example

For a quarterly VAT filer, the agent can maintain a running overview of VAT-relevant categories and surface missing receipts before the quarter closes. That matters because the deadline is fixed (end of the month after the quarter ends).

It can also track turnover for schemes like KOR (€20,000 threshold). If turnover is trending toward the threshold, the system can warn early so the business can decide how to handle VAT obligations.

From a practical “can I use this today?” perspective, bank support matters.

In our platform:

• ING: live


• Rabobank: live


• ABN AMRO: on our roadmap


• bunq: on our roadmap


• ASN Bank: on our roadmap

Across the Dutch market, many banks expose PSD2 APIs that follow Berlin Group patterns. The differences are usually in edge cases: transaction description formats, pagination, and consent UX.

What changes per bank

Even with a shared standard, each bank has quirks: transaction description formats, the way counterparty data is represented, and the consent renewal UX. That’s why we validate integrations with real data and keep a connector layer that can adapt without rewriting the whole agent.

We currently support ING and Rabobank live because they cover a large share of the Dutch market. We are expanding support over time, but we only mark a bank as “live” when the import is stable under real usage (pagination, retries, renewal flows, and edge cases).

What to look for in support

When you evaluate PSD2 bank support, ask:

• Does the connection survive consent renewals cleanly?


• Are transactions imported with stable IDs (to avoid duplicates)?


• How are account changes handled (new IBANs, closed accounts)?

These details matter more than a marketing list of logos.

PSD3 is the next iteration of European payments regulation, currently discussed in draft/proposal form. The direction is toward more standardised APIs, clearer security requirements, and expanded scope.

Topics often discussed around PSD3/PSR reforms include:

• More consistent API performance and availability requirements


• Changes in how SCA and exemptions are applied


• Broader coverage of payment products (including areas like BNPL)


• Stronger fraud prevention measures (including verification-of-payee style controls)

For bookkeeping and fintech, the main promise is fewer bank-by-bank quirks and better reliability.

Why PSD3 matters for open banking

The biggest PSD2 pain point is inconsistency. Even when banks follow the same standard, API reliability and field completeness vary. PSD3/PSR proposals aim to tighten this by making API access more consistent and reducing friction for regulated providers.

For businesses, the practical benefit would be fewer broken bank connections and fewer manual fallbacks. For agentic workflows, reliability is everything: the agent can only be as good as its data feed.

Treat PSD3 timelines as regulatory timelines: proposals and drafts do not guarantee exact delivery dates. But the direction—standardisation and stronger fraud controls—is clear.

Open finance direction

PSD3 discussions are often paired with a broader “open finance” direction: more financial products accessible through APIs, with clearer consent and security models. If that direction continues, it will expand what automation can do—but it will also increase the need for strong governance and user control.

Design guidance (so your product survives regulation changes)

Treat PSD3 as a reminder that open banking is an evolving interface. The safe engineering approach is to keep bank-specific behaviour in a connector layer, keep idempotent import logic (stable transaction IDs), and keep strong logging around what was fetched and when.

If you build workflows on top of open banking (like AI bookkeeping), also plan for expiry and reconnection as normal operations. A system that fails silently for two weeks because consent expired is worse than a system that refuses and prompts the user to reconnect.

For Dutch businesses, PSD2 open banking reduces manual work. Instead of waiting for month-end statements, your system can stay current.

That enables workflows like:

• Live categorisation with an exception queue


• Automated VAT preparation with clear evidence requirements


• Better cash-flow visibility

The biggest impact is not “more data.” It’s better timing: errors and missing receipts are detected early, when they are easy to fix.

Fintech impact

PSD2 lowered the barrier for products like personal finance tools, cash-flow dashboards, and automated bookkeeping. The AI agent layer is the next step: instead of only showing data, the system can do the work (categorise, prepare VAT overviews, surface exceptions) with guardrails and human oversight.

For Dutch MKB and ZZP’ers, the practical win is time: fewer manual exports, fewer surprises at VAT deadlines, and cleaner handover to an accountant.

Impact on accountants and bookkeepers

Open banking changes the accountant relationship. When transactions and evidence are already structured and linked, the accountant spends less time on data entry and more time on review and advice. That’s the direction we like: automation for routine work, humans for judgement.

Operational posture

Open banking works best when you treat it like a production dependency: monitor import gaps, handle renewals, and alert when the feed stalls. If you do that, PSD2 becomes a stable foundation for automation instead of a fragile integration.