FDX API vs PSD3: Open Banking Data-Sharing Architectures in

Two continents are building the same plumbing with opposite blueprints. In the United States, FDX API open banking grew bottom-up: banks, aggregators and fintechs agreed on a common schema through the Financial Data Exchange, and a federal rule (CFPB 1033) was layered on top, then frozen by a court injunction and sent back for rewriting. In the European Union, open banking was legislated top-down in PSD2, and PSD3 plus the new Payment Services Regulation (PSR) are now tightening it after a decade of uneven API quality.

The difference is not cosmetic. It decides who holds consent, who pays for access, whether screen scraping survives, what a customer can see and revoke, and how an engineer designs a token vault. This article compares the two architectures layer by layer, using only facts checked against current sources in October 2026, and flags what is still unsettled.

What this covers: the regulatory status of both regimes today, the reference architecture of each, a side-by-side decision matrix, runnable code for an FDX-style consent and token flow, and the failure modes that bite real integrations.

This is systems analysis for engineers, not legal or financial advice.

Context and Background

Open banking means a customer can instruct a regulated bank to share account data, or initiate payments, with a third party the customer chooses. The technical problem is old: before open banking, aggregators logged in as the customer using stored credentials and parsed HTML, the practice known as screen scraping. It works, but it hands a password to a third party, cannot express scope, and breaks whenever a bank redesigns its login page.

The EU moved first. PSD2 (the second Payment Services Directive) took effect for third-party access in September 2019 and created two regulated roles: the Account Information Service Provider (AISP) and the Payment Initiation Service Provider (PISP). It required banks to expose a dedicated interface, and it required strong customer authentication (SCA), meaning two of three factors from knowledge, possession and inherence. The directive did not mandate one API specification, so the market fragmented into the Berlin Group NextGenPSD2, STET, the UK-derived Open Banking Standard and others. For a deeper read on where the EU stands, see our analysis of the PSD3 and PSR open banking API architecture.

The US took the opposite path for a long time: no mandate, only bilateral contracts. Aggregators signed data-access agreements with large banks, migrated customers from scraping to tokenized OAuth connections, and converged on a shared specification run by the Financial Data Exchange (FDX), a non-profit industry body. Section 1033 of the Dodd-Frank Act had promised consumers access to their financial data since 2010, but the Consumer Financial Protection Bureau (CFPB) did not finalise an implementing rule until October 2024.

That rule did something unusual. Instead of writing a specification itself, it created a category of recognised standard-setting bodies and said that conforming to a recognised standard is evidence of compliance. FDX became the first body the CFPB recognised, according to FDX-side sources such as the Open Banking Tracker FDX profile, which also reports that FDX API v6.4 (the Spring 2025 edition) adds support for Section 1033 compliance and better consent management. I could not confirm the recognition date or the document text from a primary CFPB page in this run, so treat the exact wording as unverified.

Where each regime stands in October 2026

The status of both regimes is moving, so precision matters.

On the US side, the sequence reported by multiple law-firm and industry summaries is as follows. The CFPB issued the final rule in October 2024. Trade groups, including the Bank Policy Institute, the Kentucky Bankers Association and America’s Credit Unions, sued in the Eastern District of Kentucky in November 2024. The CFPB issued an Advance Notice of Proposed Rulemaking in August 2025 to reconsider the rule, and a court enjoined the bureau from enforcing the rule while the reconsideration proceeds. A Cozen O’Connor alert notes the original first compliance phase was due on 1 April 2026 for the largest providers. Industry commentary reports the CFPB sent its reconsideration proposal to the White House Office of Information and Regulatory Affairs (OIRA) on 6 August 2026. The proposal text is not public, so claims about what it will say, such as permitting access fees, are expectations, not facts.

On the EU side, the Council and Parliament reached a provisional political agreement on the payments package on 27 November 2025, according to the Open Banking Tracker readiness guide; the final compromise texts were reported as published on 23 April 2026 and approved by the Parliament’s economic committee on 5 May 2026. As of that source, the texts were not yet formally adopted or published in the Official Journal, with adoption expected in the second half of 2026. Most PSR rules would apply roughly 21 months after entry into force, which places the practical deadline around 2028. Anyone building against exact dates should re-check the Official Journal before committing a roadmap.

The practical consequence: US engineers are building against a de facto standard with a legally uncertain mandate, while EU engineers are building against a legally certain mandate whose technical standards (the EBA regulatory technical standards, or RTS) are not yet written.

Reference Architecture: The Same Triangle, Different Owners

Both regimes implement the same three-party pattern: a customer, a data provider (the bank), and a data recipient (the fintech or aggregator). What differs is who defines the interface, who issues credentials, who records consent, and what the regulator can inspect.

Direct answer: The FDX architecture is an industry-defined, OAuth 2.0 and FAPI-secured REST API with consent held jointly by bank and recipient, while PSD3/PSR is a law-defined access obligation where the bank must run a dedicated interface of at least the quality of its own channels, with a mandatory permissions dashboard and regulated third-party roles. FDX standardises the payload; the EU standardises the obligation.

Figure 1: US FDX-style flow. The consumer authorizes at the data provider, the recipient or aggregator receives tokens, and data moves through a tokenized API.

Figure 1 traces the US pattern. The recipient (or its aggregator) redirects the customer to the data provider’s authorization server. The customer authenticates with the bank’s own credentials, sees a consent screen, and approves a scope. The provider returns an authorization code that the recipient exchanges for an access token and a refresh token, then calls resource endpoints defined by the FDX specification.

The key architectural fact is that the password never leaves the bank. That single property is what the industry sells as the replacement for screen scraping, and it is why both the FDX ecosystem and the CFPB rule treat credential-based access as the thing to retire.

The US layer: FDX schema, OAuth, FAPI

FDX publishes a versioned REST specification covering accounts, transactions, statements, investments, insurance, tax forms and, from version 6.0 in December 2023, payroll structures for income and employment verification. The FDX release note for 6.0 also states that the spec incorporates the FAPI (Financial-grade API) security schema and adds two-way fraud notifications between participants. The latest version I could verify through a secondary source is v6.4 from mid-2025; check the FDX site for anything newer.

FAPI is an OpenID Foundation profile family that hardens OAuth 2.0 for high-risk use: pushed authorization requests, signed request objects, sender-constrained tokens through mutual TLS or DPoP, and strict redirect handling. Running FDX over FAPI means a stolen bearer token is much less useful, because it is bound to the client that received it. The adoption claim reported by the same tracker is more than 114 million consumer connections and roughly 75 percent of the addressable US market for consumer-permissioned sharing; both are vendor-reported figures, not audited numbers.

The EU layer: regulated roles, dedicated interfaces, a dashboard

PSD2 defined roles and a minimum interface; PSD3 and the PSR keep the roles but change the engineering contract. Four changes matter most to an architect, all per the readiness summaries cited above:

Interface quality. Banks must provide a data-access interface that performs at least as well as their own app or website, measured against harmonised key performance indicators. The numeric thresholds will come from EBA RTS that were not yet published when I checked.
Fallback removal. The PSD2 requirement to build a fallback interface, and the regime of exemptions from it, is removed, replaced by a supervisory contingency mechanism that competent authorities can trigger.
Permissions dashboard. Banks must give customers a dashboard to view and revoke third-party access permissions, kept in sync with the provider.
Consent and SCA. SCA is required at the first account access; the AISP may then apply its own SCA on later accesses within a window the summaries describe as roughly 180 days, replacing the PSD2-era 90-day reauthentication that was relaxed by EBA in 2022.

The dashboard rule is architecturally significant. It means the bank must hold a live, queryable record of every third-party permission and must be able to revoke one and propagate that revocation. The US rule has a similar duty on the recipient side, but the EU puts the dashboard, and therefore the system of record for consent, at the bank.

Figure 2: EU PSD3 and PSR model. The bank (ASPSP) runs a dedicated interface and a permissions dashboard; TPPs are regulated roles; supervisors can trigger contingency measures.

Figure 2 shows the EU shape. Because EU TPPs are licensed and listed, the bank can verify a caller’s regulatory identity through eIDAS qualified certificates (QWAC and QSealC), a mechanism that has no direct US equivalent. In the US, trust is created by contract and by the aggregator’s onboarding diligence of each recipient, which is why data-provider approval processes can be slow.

The structural difference in one sentence

The EU asks “is this party licensed and is the interface good enough?”; the US asks “does this party conform to a recognised standard and hold a valid consumer authorization?” Neither is strictly stronger. They fail differently, which the later sections cover.

The two regimes diverge on five engineering questions. Each is worth taking separately, because the answers drive schema design, vendor selection and cost.

A consent in either regime is a data object with a subject, a scope, a purpose, a duration and a lifecycle. The 2024 CFPB rule, as I read it, caps an authorization at one year and requires reauthorization to continue, and it requires the recipient to limit collection and use to what is reasonably necessary for the product the consumer requested. The FDX materials describe granular, time-limited permissions that the consumer can revoke at the bank or in the fintech app. Verify the exact regulatory text against the eCFR (12 CFR Part 1033) before relying on it, because the rule is under reconsideration.

In the EU, the consent semantics are split. PSD2-era practice put an “AIS consent” with the TPP and a separate “access consent” at the bank, and the two drifted out of sync. PSD3 and the PSR try to close that gap with the dashboard: the bank’s view is authoritative for access, the TPP must stay synchronised, and a revocation at either end must reach the other.

A practical model that serves both regimes is to store consent as an immutable event log and derive current state from it.

Field	Why it exists
consent_id	Stable key shared with the counterparty
subject	The customer, pseudonymised in the recipient’s store
scopes	Account types and data clusters, not endpoints
purpose	The product feature that justifies collection
granted_at, expires_at	Drives reauthorization prompts
status	active, suspended, revoked, expired
evidence	The authentication event that granted it

The evidence field matters more than teams expect. When a customer disputes a data share, the useful artefact is the exact SCA or login event and the screen text that was shown, not a boolean.

Both regimes reduce to the same security pattern: the third party gets a scoped, revocable, short-lived credential, never the customer’s password. In the US that credential is an OAuth 2.0 access token, ideally sender-constrained under FAPI. In the EU it is an access token issued by the ASPSP (the bank) after SCA, presented together with the TPP’s eIDAS certificate.

Tokenization has a second meaning in the US that does not exist in the same form in the EU: the Tokenized Account Number (TAN). When a recipient needs to move money, for example an ACH debit, it traditionally received the real account and routing numbers, which are long-lived and widely reusable. A TAN is a provider-issued substitute that maps to the real account at the bank, can be scoped to one recipient, and can be revoked without changing the underlying account. The account-number problem is real: the actual number leaks through ACH forms, cheques and breached databases, whereas a recipient-bound TAN dies with the relationship.

I could not verify from a primary FDX page how TANs are specified in the current schema, so I describe the concept, not field names. The EU reaches a similar goal differently, through IBAN-based credit transfers initiated by a licensed PISP under SCA and with dynamic linking to amount and payee.

Figure 3: Token and consent lifecycle. Grant, refresh, TAN issuance, expiry and revocation all hang off a single consent record.

Figure 3 shows why the consent record has to be the root object. Every credential, whether a refresh token or a TAN, is a child of one consent. Revoking the consent must cascade to all children, and the cascade is where integrations tend to be sloppy.

Screen scraping: banned, tolerated or phased out?

The EU answer is the clearest. Under PSD2 and its RTS, a TPP that needs to access accounts must use the bank’s dedicated interface, and the fallback interface (which in practice meant a scraping-like channel built by the bank) existed only as a safety net. PSD3 and the PSR remove the fallback obligation. If the dedicated interface fails, the replacement is supervisory action, not a second channel.

The US answer is conditional. As I read the 2024 rule, covered data providers must stand up a developer interface that third parties can use without handing over credentials, and the point was to make credential-based access unnecessary. Whether the reconsidered rule keeps this unchanged is exactly what the pending proposal will show. Meanwhile, bilateral agreements between large banks and aggregators have already moved a large share of traffic to tokenized APIs, though not all of it, and long-tail institutions remain scraped.

The engineering takeaway is to design the recipient so that scraping is a downgrade path with explicit marking, never the default. Each data point should carry a provenance flag (api or credential), because scraped data is more likely to be late, partial or mis-categorised.

Who pays for access

Fees are the sharpest policy divergence. The 2024 US rule prohibited data providers from charging for developer-interface access. Industry commentary on the August 2025 ANPRM says the fee prohibition drew some of the heaviest responses, and reporting on the pending rewrite suggests the bureau may allow some cost recovery, but the text is not public, so that is speculation, not fact.

In the EU, PSD2 effectively required free access for TPPs, and the PSR continues the principle that banks cannot charge TPPs for the mandated interface. The fee question therefore shapes architecture indirectly: if US providers may charge, aggregators will have an incentive to cache and to minimise call volume, which in turn raises staleness risk.

Decision matrix

Dimension	US FDX plus CFPB 1033	EU PSD3 plus PSR
Source of the interface spec	Industry standard body, recognised by regulator	Law sets obligations, EBA RTS set technical detail, market specs vary
Legal certainty today	Low, rule enjoined and being reconsidered	High on direction, dates pending formal adoption
Identity of third party	Contractual onboarding, aggregator diligence	Licensed and listed TPP, eIDAS certificates
Authentication	Bank login via OAuth, FAPI profile	SCA mandated, TPP-applied SCA allowed on later access
System of record for consent	Split, recipient plus provider	Bank dashboard authoritative, TPP synchronised
Fallback or scraping	Pressure to retire, not yet universal	Fallback obligation removed
Account number exposure	TANs reduce reuse	IBAN with SCA and dynamic linking
Fees for access	Prohibited in 2024 rule, under reconsideration	Free for TPPs
Coverage	Banks and some nonbanks above thresholds	Payment accounts held by regulated PSPs

Read the matrix as two answers to one question. The US has the more consistent data model and the weaker mandate; the EU has the firmer mandate and a more fragmented data model.

Reading specifications is not the same as building against them. The following sketch implements the part both regimes agree on: a consent ledger with scoped grants, expiry, tokens bound to a consent, and a revocation cascade. It uses only the Python standard library so it runs as is. It is an illustration of the data model, not an implementation of the FDX schema or a certified FAPI client.

import hashlib, secrets, time
from dataclasses import dataclass, field

DAY = 86400

@dataclass
class Consent:
    consent_id: str
    subject: str
    recipient: str
    scopes: frozenset
    purpose: str
    granted_at: float
    expires_at: float
    events: list = field(default_factory=list)  # append-only

    def status(self, now=None):
        now = now or time.time()
        if any(e[1] == "revoked" for e in self.events):
            return "revoked"
        return "expired" if now >= self.expires_at else "active"

class Ledger:
    def __init__(self):
        self.consents = {}
        self.tokens = {}   # token_hash -> (consent_id, kind)

    def grant(self, subject, recipient, scopes, purpose, days=365):
        now = time.time()
        c = Consent(secrets.token_hex(8), subject, recipient,
                    frozenset(scopes), purpose, now, now + days * DAY)
        c.events.append((now, "granted", "sca:bank-login"))
        self.consents[c.consent_id] = c
        return c

    def issue(self, consent_id, kind="access"):
        raw = secrets.token_urlsafe(32)
        h = hashlib.sha256(raw.encode()).hexdigest()
        self.tokens[h] = (consent_id, kind)
        return raw          # shown once, only the hash is stored

    def authorize(self, raw, scope):
        h = hashlib.sha256(raw.encode()).hexdigest()
        cid, _ = self.tokens.get(h, (None, None))
        c = self.consents.get(cid)
        if not c or c.status() != "active" or scope not in c.scopes:
            return False
        return True

    def revoke(self, consent_id, source):
        c = self.consents[consent_id]
        c.events.append((time.time(), "revoked", source))
        # cascade: every credential hangs off the consent
        dead = [h for h, (cid, _) in self.tokens.items() if cid == consent_id]
        for h in dead:
            del self.tokens[h]
        return len(dead)

if __name__ == "__main__":
    L = Ledger()
    c = L.grant("cust-42", "budget-app", {"accounts:read", "transactions:read"},
                "personal budgeting")
    at = L.issue(c.consent_id)
    tan = L.issue(c.consent_id, kind="tan")
    print(L.authorize(at, "transactions:read"))   # True
    print(L.authorize(at, "payments:initiate"))   # False, out of scope
    print(L.revoke(c.consent_id, "bank-dashboard"))  # 2 credentials killed
    print(L.authorize(at, "transactions:read"))   # False after revocation

Three design choices in this sketch are worth defending. First, only token hashes are stored, so a ledger leak does not leak usable credentials. Second, scopes are checked at authorization time against the consent, not embedded in the token, so narrowing a consent takes effect immediately. Third, revocation records its source (bank dashboard, recipient app, expiry job), which is the audit field that regulators and customers ask for.

To exchange the authorization code safely in the US flow, the recipient should use PKCE (Proof Key for Code Exchange, RFC 7636), and FAPI profiles go further with pushed authorization requests (RFC 9126) so that scope and redirect parameters never travel through the browser. A minimal PKCE pair looks like this:

import base64, hashlib, os

verifier = base64.urlsafe_b64encode(os.urandom(32)).rstrip(b"=").decode()
challenge = base64.urlsafe_b64encode(
    hashlib.sha256(verifier.encode()).digest()).rstrip(b"=").decode()
print(verifier, challenge)

The challenge goes in the authorization request and the verifier is revealed only at token exchange, which defeats authorization-code interception.

Capacity and latency: the part nobody specifies well

Interface quality is a measurable property. The EU intends to measure it against harmonised KPIs that the EBA RTS will define; the numbers are not published, so I will not invent any. In the US, my reading of the 2024 final rule is that it set a minimum availability target of 99.5 percent for the developer interface and a response-time target of a few seconds, but because the rule is enjoined and under revision, confirm both numbers in the current eCFR text before using them in an SLA.

What you can do without waiting for regulators is budget your own call volume. Suppose a budgeting app serves 200,000 linked customers and refreshes transactions four times a day. That is 800,000 calls a day, or about 9.3 per second on average, but real traffic is bursty because customers open apps at 08:00 and 18:00. A 10x peak factor, an assumption for illustration, gives roughly 93 calls per second against a handful of banks, and a single large bank may see a large fraction of that. If the provider throttles at 10 per second per client, you need queueing and backoff, not just retries.

Figure 4: Recipient-side integration pipeline. Every call passes a consent check and a rate limiter, and every record keeps its provenance flag.

Figure 4 sketches the pipeline I would build for either regime. A consent check gates every outbound call, a rate limiter shapes the traffic per provider, a normaliser maps provider-specific fields into an internal model, and the provenance flag follows each record to the warehouse. This is where a schema standard such as FDX pays off: normalisation is thinner because the field names already agree. In the EU, where banks implement different specifications, the normaliser is thicker, which is one reason aggregators exist there too.

If you build event-driven notifications on top of this, for example webhooks for consent revocation or new transactions, describe them formally. Our guide to AsyncAPI 3 for event-driven API specification shows how to document channels and message payloads so that partners can generate clients. The same discipline applies to bulk extracts: healthcare faced an equivalent problem in FHIR Bulk Data API analytics engineering, and the lessons about asynchronous export, backoff and idempotent retries transfer directly.

Money movement is the adjacent battleground

Data sharing is half the story. Once a recipient can read an account, the next step is initiating payments, and here the two regions differ again. The EU has a regulated payment initiation role with SCA and dynamic linking; the US relies on card networks, ACH and, increasingly, real-time rails, with open banking supplying only the account verification and tokenised credentials. Stablecoin and tokenized-deposit rules will add a third rail whose reserve and capital design is its own topic; see our analysis of the GENIUS Act stablecoin proposed rules on reserves and capital architecture for that angle. For now it is enough to note that identity and consent infrastructure built for data sharing will be reused for payments, so cutting corners on the consent ledger today creates payments risk tomorrow.

Trade-offs, Gotchas, and What Goes Wrong

Regulatory whiplash. A US recipient that built to the 2024 rule’s compliance calendar now faces an injunction and a pending rewrite. Building to FDX conformance rather than to rule text is the safer hedge, because the schema and security profile survive whichever way the rule moves. The cost is that you carry compliance logic (reauthorization cadence, data minimisation) as configuration, since the legal numbers may change.

Consent drift. The most common production defect in both regions is a mismatch between the bank’s and the recipient’s view of a consent. A customer revokes at the bank; the recipient’s refresh job keeps running, receives a 401, and the app shows a broken-connection banner for days. The fix is to treat any authorization failure as a signal to reconcile the consent, to subscribe to revocation events where the provider offers them, and to poll the dashboard-equivalent endpoint on a schedule.

Token and TAN lifetime mismatch. A TAN bound to a recipient relationship can outlive a refresh token or vice versa. If your payment product uses a TAN after the data connection has expired, the debit may fail or, worse, succeed against an authorization the customer believes is over. Align lifetimes in the ledger and test the revocation cascade.

Aggregator concentration. In the US, a small number of aggregators sit between thousands of recipients and thousands of providers. That is efficient and also a single point of failure and of liability. Contract for data portability, and know which entity actually holds the refresh tokens.

EU interface quality gaps. PSD2 shipped interfaces that were technically compliant but slow or unreliable, and removing the fallback raises the stakes: if a bank’s interface is poor, the TPP has no second channel. The harmonised KPIs are the regulator’s answer, but until the RTS exist, EU recipients should keep their own per-bank availability dashboards as evidence for supervisors.

Provenance blindness. Teams that merge scraped and API data without a flag cannot explain discrepancies. Categorisation, pending-versus-posted status and balance timing differ across channels, so the flag is a debugging tool as much as a compliance one.

Over-trusting vendor adoption numbers. Figures such as 114 million connections or 75 percent market coverage come from industry sources and count connections, not unique people. Use them for orientation, not for market sizing.

Practical Recommendations

If you are a US data recipient, build to FDX conformance with FAPI-grade security, keep the 2024 rule’s concepts (one-year authorizations, data minimisation, revocation) as configurable policy, and watch the OIRA and Federal Register signals for the reconsideration proposal. Do not assume fee-free access will survive; model what a per-call cost would do to your refresh schedule.

If you are an EU recipient or bank, plan for the permissions dashboard as a first-class system, not a UI feature. Assume the fallback interface disappears, invest in availability monitoring, and prepare for the EBA RTS to impose measurable KPIs. Track the Official Journal for the final adoption date rather than relying on press estimates.

If you operate in both regions, the shared core is the consent ledger and the token vault. Build them once with region-specific adapters on top.

A short checklist:

Store consent as an append-only event log with source and evidence on every event.
Hash tokens at rest and bind each credential to a consent_id.
Cascade revocation to refresh tokens and TANs, and test it.
Tag every record with provenance (api or credential).
Rate-limit per provider and back off on 429 and 5xx responses.
Monitor per-bank availability and latency as your own regulatory evidence.
Keep legal parameters (durations, windows, fees) in configuration, not code.
Re-verify rule status monthly; both regimes are still moving.

Frequently Asked Questions

Is the CFPB 1033 open banking rule in effect?

Not enforceably, as of the sources I checked in October 2026. The CFPB issued the final rule in October 2024, a court in the Eastern District of Kentucky enjoined enforcement while the bureau reconsiders it, and industry reports say a reconsideration proposal went to OIRA on 6 August 2026. Its text is not public. Plan for FDX conformance, treat rule-specific numbers as provisional, and check the Federal Register for the proposal.

What is the FDX API and who runs it?

The FDX API is a REST specification for consumer-permissioned financial data sharing, maintained by the Financial Data Exchange, a non-profit industry body. It covers accounts, transactions, statements, investments, insurance, tax and payroll data, and builds on OAuth 2.0 with FAPI security profiles. The 6.0 release was announced in December 2023, and a secondary source reports v6.4 from mid-2025.

Is PSD3 already law?

No, not as of the sources I found. A provisional agreement on the PSD3 and PSR package was reached on 27 November 2025, and compromise texts were reported in April 2026. Formal adoption, signature and publication in the Official Journal were still pending, with application expected roughly 21 months after entry into force. Verify the current stage in the Official Journal before setting deadlines.

Does PSD3 ban screen scraping?

Not by name in the sources I verified. What the package does is remove the PSD2 fallback-interface obligation and its exemption regime, and require a dedicated interface that performs at least as well as the bank’s own channels. In effect, banks must make API access good enough that scraping is unnecessary, with supervisors able to intervene when it is not.

What is a tokenized account number?

A tokenized account number (TAN) is a provider-issued stand-in for a real account and routing number. It maps to the account at the bank, can be scoped to one recipient, and can be revoked without changing the underlying account. It limits the damage if a number leaks. How TANs are specified in the current FDX schema is something I could not verify from a primary source.

Can one platform serve both US and EU open banking?

Yes at the core, no at the edges. The consent ledger, token vault, rate limiting and provenance tracking are shared. The edges differ: EU needs eIDAS certificates, SCA handling and a bank-side dashboard sync, while the US needs aggregator relationships, FDX schema mapping and bilateral onboarding. Build the core once and keep region adapters thin.

FDX API vs PSD3: Open Banking Data-Sharing Architectures in the US and EU