Tokenized Account Access
Tokenized account access is an OAuth-style authorization model for aggregator-to-institution data flow. The customer authenticates directly with their institution; the institution issues a refresh token to the aggregator; the aggregator presents the token on subsequent API calls. The model replaces credential-based screen-scraping and is the default for FDX-conformant institutions.
The traditional aggregator-to-institution data flow worked like this: the customer entered their institution's online-banking credentials into the aggregator's interface; the aggregator stored the credentials; the aggregator's screen-scrapers logged into the institution's website on a regular cadence using the stored credentials and parsed the resulting HTML for data. This model was the foundation of consumer-fintech aggregation for ~15 years and is the basis on which Plaid, Yodlee, and the rest built their early-stage businesses.
The model has several well-known problems. Stored credentials are a high-value security target — a compromised aggregator with millions of stored bank credentials is a worst-case incident scenario. Screen-scrapers break whenever the institution updates its website, requiring continuous engineering maintenance. The model is incompatible with multi-factor authentication in any robust way (typically requires the aggregator to relay MFA codes, which is itself a security concern). Customers have no transparent way to see or revoke aggregator access — the institution sees only legitimate logins from the aggregator using the customer's credentials.
Tokenized access replaces this. The customer authenticates directly with the institution's own login (typically embedded as an iframe or pop-up in the aggregator's onboarding flow). The institution validates credentials, handles MFA, and issues an OAuth-style refresh token to the aggregator on the customer's behalf. The token has a defined scope (which accounts, what data) and a defined lifetime (typically 90-180 days, refreshed on use). The customer can revoke the token through the institution's own interface. Subsequent aggregator API calls use the token rather than credentials.
The security improvement is substantial: no stored credentials, MFA works natively, granular scope control, customer-visible revocation. The reliability improvement is also material: tokens don't break when the institution updates its website, because the aggregator interacts with the institution's API rather than its UI. The compliance improvement (auditable access trails, customer-controlled revocation) makes the model significantly more defensible under PSD2-style and CFPB Section 1033-style regulation.
The migration from screen-scraping to tokenized access is ongoing. Akoya is fully tokenized by design. Plaid, Yodlee, and MX are progressively moving institutions onto tokenized access — typically 70-90% of their volume by mid-2026, with the long tail of small institutions remaining on screen-scraping for the time being. FDX-conformant institutions are tokenized by definition.
Synthetic data for tokenized-access integrations needs to model the token lifecycle: initial issuance, periodic refresh, expiry, and customer-revocation events. A test corpus that ships with permanent tokens cannot exercise the re-auth UX that real customers regularly trigger. Realistic test corpora include some households where token revocation has occurred mid-window and the platform has had to handle the re-auth flow gracefully.
Common pitfalls
- Treating tokens as long-lived credentials — tokens have defined lifetimes (~90-180 days) and refresh cadences; the platform has to handle expiry and refresh as routine events.
- Not handling customer-initiated revocation — customers revoke tokens through the institution; the next aggregator call returns unauthorized; the platform has to handle the re-auth flow gracefully without losing user state.
- Storing the refresh token without per-aggregator-per-institution isolation — a single leaked token compromises only the affected institution-aggregator relationship if isolation is correct, all of them if not.
- Ignoring scope limitations — token scope can be narrower than full account access (e.g. balances-only, no transactions); the platform has to handle scope mismatches.
Examples
Customer initiates account linking in the platform's UI. Platform redirects to aggregator's hosted onboarding flow. Aggregator presents an iframe of the institution's own login (handled by the institution, not the aggregator). Customer authenticates with institution credentials and MFA; institution issues refresh token to aggregator with defined scope; aggregator hands back to platform with success status. Subsequent platform → aggregator → institution data calls use the refresh token. Customer can revoke through the institution's own management interface, which immediately invalidates the aggregator's access.