💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — Eight years of PSD2, and the 2026 PSD3 opening

When PSD2 (Payment Services Directive 2) went live across the EU in January 2018, the banking industry split into two camps. "Outside companies will take our account data?" and "this will be the standard in the end." Eight years on, the second camp was right. **The EU is rolling out PSD3 + PSR (Payment Services Regulation) from 2026, and FIDA (Financial Data Access Regulation) has passed, extending Open Banking into Open Finance.**

In the US, Plaid, Finicity (Mastercard), MX and Akoya compete on top of the FDX (Financial Data Exchange) standard. In the UK and EU, TrueLayer, Tink (Visa subsidiary), Yapily and Salt Edge play the same role; Belvo handles LatAm; India runs the Account Aggregator framework (Sahamati). Korea has just hit year five of KFTC Open Banking APIs and MyData licensing, and Japan is pushing the Zenginkyo banking API guidelines into mandatory territory.

The goal of this piece is single-minded — to grasp Open Banking and Open Finance in 2026 in one breath. Standards (PSD3, FIDA, FDX, FAPI), licences (AISP, PISP, PIP), security (SCA, dynamic linking), infrastructure (aggregators) and the market structure of Korea and Japan.

1. Glossary — AISP, PISP, CBPII, SCA, FAPI

Open Banking is heavy on acronyms. Here is the short form:

| Term | Meaning | Who uses it |

| --- | --- | --- |

| AISP | Account Information Service Provider | Account access (Plaid, TrueLayer) |

| PISP | Payment Initiation Service Provider | Payment initiation (TrueLayer, Tink) |

| CBPII | Card-Based Payment Instrument Issuer | Card balance check |

| ASPSP | Account Servicing Payment Service Provider | The bank itself |

| TPP | Third Party Provider | AISP/PISP/CBPII collectively |

| SCA | Strong Customer Authentication | Two-factor user authentication |

| RTS | Regulatory Technical Standards | Technical rules from the EBA |

| FAPI | Financial-grade API (OpenID Foundation) | OAuth 2.0 with extra security |

| QSeal/QWAC | Qualified Certificates | TPP identity certificates |

| eIDAS | EU electronic identity regulation | Legal basis for QSeal/QWAC |

In the PSD2 era, RTS and eIDAS certificates guaranteed channel identity. PSD3 layers **FAPI 2.0** and stronger fraud-prevention duties on top.

2. PSD2 (2018) → PSD3 + PSR (2026) — what changes

PSD2 had two big limitations — (1) divergent national interpretations of the RTS prevented a single market, and (2) AISPs/PISPs suffered from inconsistent bank-API quality. PSD3 attacks both head on.

Key changes in PSD3 + PSR (Payment Services Regulation):

- **Single-market harmonisation**: PSR is a regulation (not a directive), so member states apply it directly.

- **API quality duties**: banks must run a dedicated interface (no screen scraping), report downtime and publish KPIs.

- **Fraud-loss allocation**: explicit rules splitting fraud liability among AISP, PISP and bank.

- **Unified AISP/PISP licence**: merged into a single PSP (Payment Service Provider) authorisation.

- **Expanded SCA exemptions**: low-value, recurring and trusted-beneficiary cases reorganised.

- **Stronger dynamic linking**: payment amount and payee must be bound to the authentication token.

PSR enters first application in January 2026, with PSD3 national transposition completing in 2027-2028. For practitioners the big thing is **API SLAs and published KPIs**. Banks can no longer leave a broken API alone.

3. FIDA — from Open Banking to Open Finance

FIDA (Financial Data Access Regulation) cleared the European Parliament in 2025 and enters force in 2026. Its core is **extending mandatory financial-data sharing from payments/accounts into insurance, pensions, investments and mortgages**.

Where PSD3 covers payments and accounts, FIDA covers everything else. Mandatory sharing targets:

- Mortgage and consumer-loan balances and amortisation schedules.

- Deposits, term deposits, money market funds.

- Insurance — life, motor, home, travel.

- Pensions — private and workplace.

- Investment and securities accounts — holdings, fills, valuations.

- Crypto-asset holdings (linked to MiCA).

FIDA introduces a new concept — **FISP (Financial Information Service Provider)**. If AISP was payments/accounts, FISP covers the rest. **FIDP (Financial Data Provider)** is the data-providing side.

On the regulatory side FIDA introduces a clearer compensation model — FIDPs can charge a reasonable fee for providing data. That differs from PSD2's free regime, and it creates incentives for banks, insurers and pension funds to run high-quality APIs.

4. Plaid — the company that became the US Open Banking standard

Plaid started in San Francisco in 2013. It became the bank-connection infrastructure for fintechs such as Venmo, Robinhood and Acorns, and by 2026 it processes data tied to `$50B transactions` across the US, Canada and EU (self-reported estimate).

Plaid product lines:

- **Plaid Link**: the widget where users pick their bank and connect via OAuth or credentials.

- **Transactions API**: pulls transaction history.

- **Auth**: verifies account and routing numbers.

- **Identity**: identity for KYC.

- **Balance**: real-time balance.

- **Income**: income verification.

- **Assets**: asset reports (loan underwriting).

- **Liabilities**: student loan, credit card, mortgage balances.

- **Investments**: securities holdings and fills.

- **Signal**: ACH fraud risk score.

Plaid Link JavaScript example (conceptual):

// Plaid Link — client-side flow

const handler = Plaid.create({

token: linkToken, // a link_token pre-generated on the server

onSuccess: async (publicToken, metadata) => {

// The client only receives publicToken.

// Send it to the server to exchange for an access_token.

await fetch('/api/plaid/exchange-public-token', {

method: 'POST',

headers: { 'Content-Type': 'application/json' },

body: JSON.stringify({ public_token: publicToken })

})

onExit: (err, metadata) => {

if (err) console.error('plaid_exit', err)

onEvent: (eventName, metadata) => {

// OPEN, SELECT_INSTITUTION, SUBMIT_CREDENTIALS, HANDOFF, ERROR ...

}

})

handler.open()

Server-side token exchange:

// Server — exchange public_token for access_token

const client = new PlaidApi(new Configuration({

basePath: PlaidEnvironments.production,

baseOptions: {

headers: {

'PLAID-CLIENT-ID': process.env.PLAID_CLIENT_ID,

'PLAID-SECRET': process.env.PLAID_SECRET,

}))

async function exchange(publicToken) {

const res = await client.itemPublicTokenExchange({ public_token: publicToken })

// res.data.access_token — the user's access token

// res.data.item_id — the Plaid Item identifier

return res.data

}

After Visa's 2022 attempt to acquire Plaid fell apart on US DOJ antitrust grounds, Plaid has been on an independent track. A 2026 IPO has been heavily reported.

5. TrueLayer, Tink, Yapily — the UK/EU aggregator Big Three

Three companies dominate UK and EU Open Banking infrastructure.

- **TrueLayer** (2016, London): strong on PISP payments. Used by eBay, Revolut and even charity giving as a payment rail. Combines AISP and PISP.

- **Tink** (2012, Stockholm → acquired by Visa in 2022): broad EU coverage starting from PFM (personal finance management). Post-Visa, fused with Visa Direct for end-to-end payment and settlement.

- **Yapily** (2017, London): pitches itself as a "headless" AISP. No UI; only APIs, so fintechs can build their own UX.

TrueLayer payment-initiation (PISP) example:

// TrueLayer — create a payment intent (server-side)

const res = await fetch('https://api.truelayer.com/payments/v3', {

method: 'POST',

headers: {

'Authorization': `Bearer ${accessToken}`,

'Idempotency-Key': idempotencyKey,

'Content-Type': 'application/json',

body: JSON.stringify({

amount_in_minor: 1099,

currency: 'GBP',

payment_method: { type: 'bank_transfer', provider_selection: { type: 'user_selected' } },

beneficiary: {

type: 'merchant_account',

merchant_account_id: 'acc_xxx',

account_holder_name: 'Example Ltd'

user: { id: 'usr_123', name: 'Alice', email: 'alice@example.com' }

})

const payment = await res.json()

// Use payment.resource_token + redirect URL for user auth → payment complete

Since becoming a Visa subsidiary, Tink has bundled with Visa Direct and CyberSource to globalise its payment and settlement footprint. Even where TrueLayer outguns it on standalone AISP, Tink uses Visa's weight to push into LatAm and Asia.

Yapily's differentiator is its white-label model. The fintech owns all UI; Yapily only receives API calls. That gives the fintech freedom on regulation and UX, but transfers UX-design burden onto it.

6. Belvo, Salt Edge — LatAm and global coverage

- **Belvo** (2019, Mexico City + Madrid): the de facto LatAm Open Banking standard. Bank API integrations across Mexico, Brazil, Colombia, Chile and Argentina. Infrastructure for fintechs such as Konfío, Bitso and Clip.

- **Salt Edge** (2013, Toronto): "global coverage" as the weapon. 50+ countries, 5,000+ financial institutions on a single API — EU, UK, US, parts of Asia, LatAm and the Middle East.

One of Belvo's special workloads is integrating **PIX**, Brazil's instant payments system. PIX is run by the central bank and serves the same role as SEPA Instant in the EU or Korea's instant transfers in Open Banking. After Brazil's payment rails completed their effective shift to PIX in 2026, Belvo started offering PIX payment initiation as a PISP-style flow.

// Belvo — PIX payment initiation example (conceptual)

const res = await fetch('https://api.belvo.com/payments/payment-intents/', {

method: 'POST',

headers: {

'Authorization': 'Basic ' + btoa(`${secretId}:${secretPassword}`),

'Content-Type': 'application/json',

body: JSON.stringify({

amount: '49.90',

currency: 'BRL',

description: 'Order #12345',

payment_method_type: 'pix',

callback_urls: { success: 'https://example.com/ok', error: 'https://example.com/err' },

customer: { name: 'Maria Silva', email: 'maria@example.com', document_id: '12345678901' }

})

Salt Edge's edge is breadth. To deliver a consistent data model across 5,000 institutions it runs its own taxonomy. That powers transaction categorisation (rent, groceries, transport and so on).

7. Finicity, MX, Akoya — the US in the FDX era

The US took a different road from the EU. There was no top-down PSD2; instead a market-led FDX (Financial Data Exchange) functioned as the standard. With the CFPB's Section 1033 rule live in 2026, the US enters its serious-regulation phase.

- **Finicity** (2000, Utah → acquired by Mastercard in 2020): strong on asset verification, income verification and mortgage underwriting. Synergy with payments and credit post-Mastercard.

- **MX** (2010, Utah): PFM backend for banks and credit unions. Strong on data cleaning and categorisation.

- **Akoya** (2018, Boston): a joint venture between Fidelity and eight large US banks. Consortium model — the "aggregator banks built".

The CFPB's Section 1033 (Personal Financial Data Rights Rule) was finalised in October 2024. Highlights:

- Consumers own the right to their financial data.

- Data holders (banks) must provide data to the consumer or their nominated TPP, free of charge.

- FDX is effectively recognised as the standard.

- Screen scraping is on a phased ban schedule.

{

"fdx_api_version": "6.0",

"endpoint": "GET /accounts/{accountId}/transactions",

"permission_scope": "ACCOUNTS_DETAIL_READ TRANSACTIONS_READ",

"rate_limits": {

"per_consumer_per_day": 4,

"burst": 30

"auth": "OAuth 2.0 + DPoP",

"data_format": "FDX Common Schema"

}

The US market is in a major sorting phase in 2026. Screen scraping is shrinking, OAuth/FDX APIs are growing. Plaid, Finicity, MX and Akoya are each digging in to their positioning.

8. FAPI 2.0 — the financial-grade OAuth standard

OAuth 2.0 is good, but too weak for finance. The OpenID Foundation's **FAPI (Financial-grade API)** hardens OAuth for finance. FAPI 2.0 became the standard in 2026.

Key strengthenings in FAPI 2.0:

- **PAR (Pushed Authorization Requests)**: the client pushes authorisation parameters to the server in advance. Solves URL length and exposure issues.

- **mTLS** or **private_key_jwt**: stronger client authentication.

- **DPoP (Demonstrating Proof-of-Possession)**: access token bound to a client key. Stolen tokens become unusable.

- **RAR (Rich Authorization Requests)**: spell out fine-grained permissions (amount, payee, period).

- **JARM**: responses signed as JWS.

End-to-end flow example:

POST /par HTTP/1.1

Host: as.bank.example

Content-Type: application/x-www-form-urlencoded

response_type=code

&client_id=tpp_acme

&redirect_uri=https%3A%2F%2Ftpp.example%2Fcb

&scope=accounts%20payments

&authorization_details=%5B%7B%22type%22%3A%22payment_initiation%22%2C%22amount%22%3A%7B%22currency%22%3A%22EUR%22%2C%22value%22%3A%2299.99%22%7D%2C%22creditor%22%3A%7B%22iban%22%3A%22DE89370400440532013000%22%7D%7D%5D

&code_challenge=...&code_challenge_method=S256

&state=xyz

The response carries a `request_uri` that builds the authorisation URL. The user performs SCA at the bank, the callback delivers a `code`, and the client exchanges it at the token endpoint with mTLS and DPoP to receive an access_token.

PSD3 effectively recommends FAPI 2.0, and by 2027-2028 nearly all EU ASPSPs are expected to run FAPI 2.0-compliant authorisation servers.

9. SCA — Strong Customer Authentication in detail

SCA is the security core of PSD2. It combines two different factors:

- Knowledge: password, PIN.

- Possession: phone, token.

- Inherence: biometric.

PSD2 SCA is mandatory for payments and account access, with exemptions:

| Exemption | Condition | Use |

| --- | --- | --- |

| Low value | `<EUR 30` (cumulative EUR 100 or 5 transactions cap) | Contactless cards |

| Trusted beneficiary | User added to trusted list | Recurring transfer |

| Recurring payment | Same amount recurring | Subscription |

| Corporate payment | Secure corporate payment systems | B2B |

| TRA (Transaction Risk Analysis) | TPP under fraud-rate threshold | Merchant or issuer |

| Unattended terminals | Tolls, parking | Automatic |

| One auth per 90 days | Same TPP and account | AISP data refresh |

PSD3 focuses on **stronger TRA** and **relaxed 90-day AISP re-authentication**. PSD2 RTS's hard 90-day SCA is being relaxed, which improves the UX of mobile and wealth-management apps.

Dynamic linking is the other SCA core. The authentication token must include the payment amount and payee. This stops MITM attacks from altering payment details.

10. Korea's Open Banking — KFTC's 100+ APIs

Korea fully launched Open Banking in December 2019. The Korea Financial Telecommunications and Clearings Institute (KFTC) operates a central hub through which banks, securities firms and e-finance operators connect via APIs.

Status (as of 2026, estimated):

- Participants: 19 banks, mutual finance, savings banks, post office, card issuers, fintechs.

- Core APIs: balance enquiry, transaction history, withdrawal transfer, deposit transfer, account real-name check, beneficiary verification — about 100 in total.

- Volume: hundreds of millions of calls per day, cumulative transfers in the tens of trillions of won.

- Pricing: standardised fees keep fintech entry low.

KFTC's OpenAPI builds on standard OAuth 2.0 with dynamic client registration. Dynamic linking and SCA are standardised too.

GET /v2.0/account/balance/fin_num

?bank_tran_id=M202612340U001234567

&fintech_use_num=199912345678901234

&tran_dtime=20260525120000

Authorization: Bearer {access_token}

Response example:

{

"api_tran_id": "f1234567-1234-5678-9abc-1234567890ab",

"rsp_code": "A0000",

"rsp_message": "OK",

"bank_code_std": "088",

"balance_amt": "1250000",

"available_amt": "1250000",

"account_type": "1",

"product_name": "Corporate Savings",

"bank_tran_id": "M202612340U001234567",

"bank_tran_date": "20260525",

"api_tran_dtm": "20260525120000123"

}

Standardised Open Banking let Toss, Kakao Bank, Banksalad and Finnq compose multi-bank account aggregation in a short time. As of 2026 Korean Open Banking is at PSD2-equivalent maturity, but the licence structure differs — EU has AISP/PISP, Korea has e-finance + MyData (personal credit information management).

11. Korea MyData — personal credit information management

MyData launched in earnest in January 2022, with the amended Credit Information Use Act as its legal basis for the personal credit information management licence. As of 2026 there are 60+ licensees.

Headline players:

- Banks: Shinhan, KB Kookmin, Hana, Woori, NH Nonghyup, IBK, SC Cheil, DGB, BNK, iM, Jeonbuk, Gwangju, Jeju.

- Cards: Shinhan, Samsung, KB, Hyundai, Lotte, Woori, Hana, BC, NH.

- Fintechs: Kakao Bank, Toss, Banksalad, Finnq, Payco, Naver Pay, Kakao Pay, NHN Payco.

- Securities: Mirae Asset, NH Investment, Samsung, KB, Kiwoom, Korea Investment, Shinhan Investment.

- Insurance: Samsung, Hanwha, Kyobo, Shinhan, KB, Tongyang, Mirae Asset.

MyData covers a broader data scope than Open Banking.

| Domain | Data |

| --- | --- |

| Banking | Accounts, transactions, loans, FX |

| Cards | Payments, authorisations, billing, instalments, overseas |

| Securities | Holdings, fills, prices, valuations |

| Insurance | Policies, premiums, claims, surrender |

| Telecom | Telecom bills |

| Public | National tax, customs, pensions |

| Health | Medical (Health MyData expansion in 2024) |

The MyData unified authentication API lets users access data at multiple institutions in a single sign-on. Unified Auth 1.0 launched in 2022; Unified Auth 2.0 arrived in 2024, strengthening OIDC + DID integration.

POST /oauth/2.0/token

Host: api.mydatakorea.example

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code

&client_id={organisation_code}

&client_secret={secret}

&code={authorisation_code}

&redirect_uri={redirect}

&org_code={data_provider_code}

MyData's strengths are broad scope and standardised consent. The downside is operational overhead — different providers have different API quality, refresh schedules and organisation codes. KFTC and Korea Credit Information Services are working together on more standardisation.

12. Kakao Bank and Toss — Korea MyData's two models

The two biggest players in Korean MyData are Kakao Bank and Toss (Viva Republica). Same licence, different business models.

- **Kakao Bank**: an internet-only bank as core business, plus MyData. Strong on asset aggregation, spending analysis and credit scoring.

- **Toss**: a general-purpose financial platform. Channels aggregated MyData into Toss Securities, Toss Bank and Toss Insurance.

Toss's strength is integrated UX. Users see their entire financial life inside the Toss app. Kakao Bank wins on messenger-friendly UX and gamified products such as the 26-week savings plan.

The next phase of MyData is **SME and sole-trader MyData**. Sales, purchases, taxes and payroll are bundled to accelerate SME lending. Pilots ran in 2025-2026.

13. Japan's Zenginkyo APIs — moving toward mandatory

Japan amended its Banking Act in 2017 to create the **electronic payment service intermediary** licence, equivalent to the EU's AISP/PISP. Between 2018 and 2020 Zenginkyo (the Japanese Bankers Association) published Banking API guidelines, and 2024-2026 marks the move toward mandatory adoption.

Operating structure:

- ASPSP-equivalent Japanese banks — SMBC, MUFG, Mizuho, Resona, plus regional banks.

- Electronic payment service intermediaries: Money Forward, freee, Moneytree, Nudge.

- Zenginkyo operates the API standard and connection rules.

SMBC, MUFG and Mizuho each run their own APIs, but follow the Zenginkyo guideline. Most APIs use OAuth 2.0 + FAPI 1.0; some banks are preparing FAPI 2.0.

GET /v1/accounts/{accountId}/balance

Host: bankapi.smbc.example

Authorization: Bearer {access_token}

x-fapi-financial-id: ZNG-2026-SMBC

x-fapi-interaction-id: 5a8e2b1c-...

200 OK

{

"Data": {

"Account": [{

"AccountId": "ACC-2026-001234",

"Currency": "JPY",

"AvailableBalance": "523450",

"BookedBalance": "523450"

}]

}

A Japanese peculiarity is the **clear separation between PSPs and banks**. Electronic payment services such as PayPay, LINE Pay and Rakuten Pay auto-load from bank accounts through bank APIs; users top up the PSP wallet rather than spending bank balance directly.

Money Forward and freee are the standard bearers of Japanese PFM and accounting SaaS. They consume bank APIs to deliver integrated accounting for sole traders and SMEs — close to the US Mint and QuickBooks playbook.

14. Japan JFSA guidelines and the 2026 direction

The Japanese Financial Services Agency (JFSA) published its "Open Banking Promotion" policy in 2024. Headlines:

- Standardise and publish KPIs for bank APIs.

- Tighten security and operational standards for electronic payment intermediaries.

- Recognise a right to data portability.

- Extend to insurance, securities and pensions — close to the EU's FIDA direction.

In 2025 JFSA published its "Basic Policy on Financial Data Utilisation", explicitly aiming at expansion into Open Finance. A Japanese specificity is **dual governance between the Personal Information Protection Commission and JFSA**. The Personal Information Protection Act (amended 2022) sets the data-protection baseline, and JFSA adds financial-specific rules.

Industry signals:

- SMBC: SMBC Cloud Sign + APIs. Building in-house AI credit scoring.

- MUFG: GO-NET and MUFG Coin in its digital strategy. APIs standardised.

- Mizuho: J-Coin Pay + bank APIs.

- Resona: doubling down on data analytics and corporate APIs.

- Rakuten Bank: internet bank, integrated into the Rakuten economic zone.

- PayPay Bank (formerly Japan Net Bank): PayPay integration.

15. US Section 1033 in force — Open Banking becomes law

There was no government-led PSD2 in the US, but the CFPB's Section 1033 (Personal Financial Data Rights Rule) was finalised in October 2024 and is in effect a US PSD2.

Key duties:

- Data holders must provide the consumer or their delegated TPP with one year of transactions, balances and basic account information, free of charge.

- FDX is effectively recognised as the data format.

- Screen scraping is on a phased ban schedule.

- Explicit consumer consent is required for data use.

- Secondary use of data is restricted.

The compliance timeline applies phased by asset size — large banks by April 2026, mid-size by October 2026, smaller institutions through 2027.

The US Open Banking ecosystem is therefore entering a PSD2-EU-like standardisation curve. Plaid, Finicity, MX and Akoya become FDX-compliant API operators, and screen scraping dependency shrinks.

16. Security and fraud — dynamic linking and token binding

The two security pillars of Open Banking are **dynamic linking** and **token binding**.

Dynamic linking: the payment authentication token must include amount and payee. This stops MITM attacks from altering the payment.

Token binding: the access_token must be bound to a client key or device. DPoP and mTLS implement this.

DPoP header — binds the token to a client key

POST /payments HTTP/1.1

Host: as.bank.example

Authorization: DPoP eyJraWQiOiJ...access_token...

DPoP: eyJ0eXAiOiJkcG9wK2p3dCIs...signed_proof...

DPoP binds the access_token to the client's public key and the client signs a fresh proof JWT on every request. Even if the access_token is stolen, it is unusable without the private key.

Additional fraud signals:

- Device fingerprint, IP geo, session behaviour.

- Behaviour biometrics (typing patterns, mouse movement).

- Transaction graph — products such as Plaid Signal and TrueLayer Trust score ACH and payment fraud risk.

PSD3 + PSR's liability rules make TPP, ASPSP and consumer responsibilities explicit when fraud losses occur — a clarity PSD2 lacked.

17. Categorisation — turning transactions into meaning

The value of Open Banking data is not in the raw stream. It becomes meaningful when transactions are classified into "Starbucks coffee", "rent" or "transport". Categorisation is core IP for every aggregator and PFM app.

Standard taxonomy:

| Top level | Sub category |

| --- | --- |

| Food | Dining out, delivery, groceries, cafes |

| Transport | Public transit, taxi, fuel, parking, tolls |

| Housing | Rent, maintenance, utilities, internet |

| Telecom | Mobile, internet, subscriptions |

| Shopping | Apparel, electronics, furniture, daily goods |

| Entertainment | Cinema, games, OTT, travel |

| Health | Medical, pharmacy, gym |

| Education | Tutoring, textbooks, professional |

| Finance | Insurance, loan repayments, investment |

| Transfers | Personal transfer, international transfer |

How categorisation works:

Transaction categorisation — rules + ML hybrid (conceptual)

from typing import Dict

RULES = [

(r"STARBUCKS", "Food/Cafe"),

(r"UBER|LYFT", "Transport/Ride-hail"),

(r"NETFLIX|DISNEY\+", "Entertainment/OTT"),

(r"WHOLE\s?FOODS|TRADER\s?JOE", "Food/Groceries"),

]

def rule_categorize(memo: str) -> str | None:

for pattern, cat in RULES:

if re.search(pattern, memo, re.IGNORECASE):

return cat

return None

Fall through to an ML model if rules miss

def hybrid_categorize(tx: Dict, ml_model) -> str:

cat = rule_categorize(tx.get("memo", ""))

if cat:

return cat

return ml_model.predict([tx])[0]

On the regulatory side, categorisation flows into credit scoring, marketing and even benefit eligibility, so the US, EU and Korea all require monitoring of accuracy and bias.

18. India's Account Aggregator — another model

India took yet another path. The Reserve Bank of India (RBI) created the **Account Aggregator (AA)** framework in 2016 with a new NBFC-AA licence that separates the role of data intermediary.

Characteristics:

- Consent-manager-centric model.

- FIP (Financial Information Provider) — banks, securities firms, pension funds and others.

- FIU (Financial Information User) — data consumers.

- AA — the consent, routing and encryption intermediary. AAs do not see the data.

- ReBIT (Reserve Bank IT) maintains the standard. Sahamati is the industry alliance.

The AA model differs from the EU. The AA does not see the data; it only routes. Data flows directly from FIP to FIU, while the AA guarantees consent integrity, audit logs and encryption.

This model also influenced parts of Korean MyData design. The difference is that Korea allows its personal credit information management licensees to aggregate and display data themselves.

19. Open Finance — expanding into insurance, pensions and investment

If PSD2 covered payments and accounts, Open Finance covers all the rest of finance. FIDA is the EU's starting gun, and Korea, Japan and the US are on similar paths.

Signals of expansion:

- Insurance: life, motor and home coverage and claims data shared with other insurers and comparison marketplaces.

- Pensions: workplace and private pension balances, contributions and projected payouts.

- Investments: brokerage holdings, executions, valuations and fees.

- Mortgage: balance, rates, schedules — accelerating refinancing comparisons.

- Crypto assets: integrated with MiCA and VASP rules.

Technical standards stay the same as PSD2/PSD3 — OAuth 2.0 + FAPI 2.0 + JSON API. Only data models are redefined per domain. EBA and EIOPA are publishing standardisation guidance.

Korean MyData already looked like Open Finance from the start — insurance, securities, telecom and public data were in scope from day one. Japan starts from bank APIs and expands stepwise to insurance and securities.

20. TPP licensing — where and how to obtain it

To run Open Banking or Open Finance you need a TPP licence. By country:

| Country | Licence | Supervisor |

| --- | --- | --- |

| EU | AISP, PISP (merged into a single PSP) | National authority + EBA |

| UK | AISP, PISP (FCA registration) | FCA |

| US | No single licence. State MTLs and others | CFPB, OCC, FinCEN |

| KR | Electronic finance, MyData (personal credit information mgmt) | FSC, FSS |

| JP | Electronic payment service intermediary | JFSA |

| BR | Open Finance phased licences | BCB (central bank) |

| IN | NBFC-AA | RBI |

| MX | Fintech Law licence | CNBV |

The most common EU path is to obtain a licence in a smaller member state such as Lithuania, Ireland or Luxembourg and use EU passporting. Post-Brexit the UK requires separate registration.

In Korea a MyData licence cannot be obtained by simple application. There are requirements for KRW 500M+ in capital, security systems, monitoring, staffing and financial soundness. In Japan systems-operations, financial audit and information-protection standards are stringent but capital requirements are comparatively light.

21. Infrastructure choice — build vs aggregator

Fintechs adopting Open Banking face two paths — direct ASPSP integration or using an aggregator.

| Item | Build direct | Aggregator (Plaid/TrueLayer/Tink/Belvo/Salt Edge) |

| --- | --- | --- |

| Upfront cost | High (licence, certificates, testing) | Low (monthly fees) |

| Run cost | Low (no per-call fee) | Per-call or per-user |

| Time | 6-18 months | 1-2 weeks |

| Coverage | What you integrate | Hundreds to thousands of institutions |

| Reliability | Your responsibility | Aggregator owns |

| Data standardisation | You normalise | Aggregator normalises |

| Regulatory liability | Direct | Shared (TPP + processor responsibility) |

Most startups begin with an aggregator and move to a hybrid — direct integrations only for core markets once they reach scale. Example: Wealthsimple integrates large Canadian and US banks directly, smaller institutions via Plaid.

22. Practical example — building a consolidated wealth dashboard

A consolidated wealth dashboard is the canonical Open Banking and MyData use case. One screen shows the user's assets across multiple banks, brokerages, cards and insurers.

Design flow:

1. User signup and OAuth consent across multiple institutions.

2. Store access_token and refresh_token in a secured KMS.

3. Periodic sync (combine caching and pulling to keep `<2초 API call` response times).

4. Normalisation — currency, balances and asset classes.

5. Display — balances, time-series, allocation and goals.

// Consolidated wealth dashboard — sync job (conceptual)

async function syncAllAccounts(userId) {

const userTokens = await tokenStore.list({ userId })

// Concurrent calls (Plaid + MyData + bank APIs)

const results = await Promise.allSettled(

userTokens.map(async (t) => {

switch (t.provider) {

case 'plaid':

return await plaid.balances(t.accessToken)

case 'kr_mydata':

return await krMydata.accounts(t.accessToken, t.orgCode)

case 'jp_smbc':

return await jpSmbc.accounts(t.accessToken)

case 'truelayer':

return await truelayer.accounts(t.accessToken)

}

})

)

// Map results to a normalised model

return normalize(results)

}

Operational issues:

- Token expiry (typically 90 days). PSD3 relaxes AISP 90-day re-auth and improves UX.

- Currency conversion when aggregating across institutions — reliability of FX sources.

- Categorisation and dedupe — card payments and bank withdrawals can appear twice.

- Downtime handling — make sure a single failing institution does not break the screen.

23. Comparison — US/EU/KR/JP regulatory matrix

| --- | --- | --- | --- | --- |

24. Operating checklist — before a TPP or fintech ships

A working checklist to close.

1. **Licence**: obtain the country's TPP licence (or use EU passporting).

2. **eIDAS certificates**: issue QSeal/QWAC — Buypass, Globalsign, Sectigo and similar.

3. **Sandbox conformance**: pass conformance in each ASPSP sandbox.

4. **FAPI 2.0 compatibility**: PAR + DPoP + mTLS or private_key_jwt.

5. **SCA UX**: smooth flows for dynamic linking and the 90-day re-auth.

6. **Monitoring**: API availability, latency and error distributions.

7. **Token security**: KMS- or HSM-backed private key storage.

8. **Data minimisation**: store only the data inside the consent scope.

9. **Categorisation quality**: accuracy and bias monitoring on classification.

10. **Fraud detection**: device fingerprint, behaviour and graph combined.

11. **Regulatory reporting**: forms for fraud losses, downtime and complaints.

12. **Consumer rights**: consent withdrawal and data deletion automation.

13. **Disaster recovery**: fallbacks for ASPSP downtime and your own outages.

14. **Vendor governance**: aggregator, KMS and authorisation-server SLAs and test results.

These 14 items are the 2026 standard. The key point — **the core Open Banking values of connectivity, consent and standardisation are now married to fintech speed and engineering**. Across the regulatory lattice formed by PSD3, FIDA, Section 1033, MyData and Zenginkyo, Plaid, TrueLayer, Tink, Yapily, Belvo, Salt Edge, Finicity, MX, Akoya, KFTC and Money Forward build the rails. The user, through a single consent, can see their entire financial life.

References

- Plaid — [https://plaid.com/](https://plaid.com/)

- TrueLayer — [https://truelayer.com/](https://truelayer.com/)

- Tink (Visa) — [https://tink.com/](https://tink.com/)

- Yapily — [https://www.yapily.com/](https://www.yapily.com/)

- Belvo — [https://belvo.com/](https://belvo.com/)

- Salt Edge — [https://www.saltedge.com/](https://www.saltedge.com/)

- Finicity (Mastercard) — [https://www.finicity.com/](https://www.finicity.com/)

- MX — [https://www.mx.com/](https://www.mx.com/)

- Akoya — [https://akoya.com/](https://akoya.com/)

- Korea Financial Telecommunications and Clearings Institute (KFTC) Open Banking — [https://www.kftc.or.kr/](https://www.kftc.or.kr/)

- MyData Center (Korea) — [https://www.mydatacenter.or.kr/](https://www.mydatacenter.or.kr/)

- Korea Credit Information Services — [https://www.kcredit.or.kr/](https://www.kcredit.or.kr/)

- Financial Services Commission (Korea) — [https://www.fsc.go.kr/](https://www.fsc.go.kr/)

- Financial Supervisory Service (Korea) — [https://www.fss.or.kr/](https://www.fss.or.kr/)

- Japanese Bankers Association (Zenginkyo) — [https://www.zenginkyo.or.jp/](https://www.zenginkyo.or.jp/)

- Japan Financial Services Agency (JFSA) — [https://www.fsa.go.jp/](https://www.fsa.go.jp/)

- EBA Open Banking — [https://www.eba.europa.eu/](https://www.eba.europa.eu/)

- EIOPA — [https://www.eiopa.europa.eu/](https://www.eiopa.europa.eu/)

- ESMA — [https://www.esma.europa.eu/](https://www.esma.europa.eu/)

- CFPB 1033 Rule — [https://www.consumerfinance.gov/rules-policy/final-rules/personal-financial-data-rights/](https://www.consumerfinance.gov/rules-policy/final-rules/personal-financial-data-rights/)

- FDX (Financial Data Exchange) — [https://financialdataexchange.org/](https://financialdataexchange.org/)

- OpenID FAPI 2.0 — [https://openid.net/specs/fapi-2_0-security-profile.html](https://openid.net/specs/fapi-2_0-security-profile.html)

- Sahamati (India AA) — [https://sahamati.org.in/](https://sahamati.org.in/)

- Money Forward — [https://moneyforward.com/](https://moneyforward.com/)

- freee — [https://www.freee.co.jp/](https://www.freee.co.jp/)