Open banking sits at the intersection of data access regulation, financial infrastructure, and credit model engineering. The concept is straightforward in the abstract: give financial platforms permissioned access to a consumer's bank account transaction history, and you can compute credit signals that no bureau file contains. The implementation is considerably more complex. This primer walks through the full stack — from the API connection layer to the point where cleaned features enter a credit model.
We're writing this from the perspective of building a production credit decisioning system on top of bank transaction data, not as a survey of the open banking ecosystem. The choices we've made reflect what works at the level of accuracy and latency required for real-time credit decisions, not what's simplest to prototype.
The data access layer: aggregators and direct connections
Most lenders integrating bank transaction data start with a bank data aggregator — a middleware layer that handles institution connectivity, credential management, and OAuth flows, and returns normalized transaction data regardless of which bank the applicant uses. The aggregator abstracts away the problem of maintaining direct API connections with thousands of financial institutions.
The US market has several mature aggregators operating at scale. Their coverage of US financial institutions varies — major national banks and large credit unions are universally covered; smaller community banks and credit unions less so. For a lender targeting thin-file populations, coverage matters: a significant portion of this demographic banks with regional or community institutions, and incomplete aggregator coverage introduces selection bias into your data collection.
The alternative to aggregators is direct FDX (Financial Data Exchange) API integration with institutions that have published consumer-permissioned APIs. FDX is the US open banking standard, accelerated in scope by the CFPB's Section 1033 rulemaking. Direct FDX connections offer better data freshness and more granular transaction attributes than legacy aggregator screen-scraping methods, but require institution-by-institution integration work that's only practical for the largest institutions.
The practical answer for a growing lender: start with aggregator coverage, build FDX direct connections for the five to ten largest institutions in your applicant population, and accept degraded coverage at the long tail. Monitor your coverage rate continuously — the fraction of applicants who successfully complete bank connection is a critical funnel metric that interacts directly with your approval rate on thin-file applicants.
Raw transaction data: what you get and what it means
A typical transaction record from an aggregator includes: transaction date, settlement date, amount (signed: negative for debits, positive for credits), merchant name or description, merchant category code (MCC) if applicable, account ID, and sometimes a pending/settled status flag. What you do not reliably get: a clean category label, an accurate payee identification, or any indication of whether this transaction represents a recurring obligation.
The merchant name field is particularly unreliable. The same rent payment to the same landlord might appear as "JOHN SMITH PROP", "JSMI PROPERTIES LLC", "ZELLE PAYMENT - JOHN S", or "PMNT REF 998821XXX" depending on the payment method. Transaction categorization — the process of mapping raw descriptions to semantically meaningful categories — is a significant engineering challenge that is often underestimated.
For credit risk feature engineering, the categories that matter most are:
- Regular income deposits — payroll, direct deposit, ACH from employers or gig platforms
- Housing payments — rent payments via ACH, check, Zelle, or third-party rent services
- Utility and telecom payments — electric, gas, water, internet, mobile
- Existing loan or BNPL payments — payments that look like installment obligations not captured by the bureau
- Cash withdrawal activity — ATM and cash-equivalent transactions, which can indicate reliance on cash economy
- NSF / overdraft markers — returned items, overdraft fees, which are high-signal negative indicators
Accurate categorization of these specific types is more important than general-purpose spending category accuracy. A credit model that knows precisely when rent is paid and whether it's on time is more predictive than one that knows whether someone shops at grocery stores.
The lookback window decision
How many months of transaction data do you request? The answer depends on which features you're computing and what your applicant population looks like.
The minimum viable window for any income verification is three months — enough to establish a pattern and filter out one anomalous period. Twelve months captures a full seasonal cycle, important for applicants with seasonal income patterns. Twenty-four months is where structural financial behavior features — income trend direction, obligation payment consistency, net cash flow trajectory — reach meaningful discriminatory power.
The cost of a longer lookback is friction: asking an applicant to connect a bank account going back 24 months means the aggregator needs to page through a larger transaction set, which increases latency in the data retrieval step. For some institutions, deep transaction history requires multiple API calls with pagination, adding 2–4 seconds to the data collection phase.
At Lendiro, we request 24 months as the target, fall back to 12 months if the account is newer, and flag applications with less than 6 months of history as insufficient for our primary model. The 6-month minimum is a hard threshold below which feature reliability degrades enough that the model's predictions become unreliable.
Feature engineering: from transactions to model inputs
The transformation from raw transaction sequences to model-ready features is the core intellectual work in cash-flow underwriting. This section is necessarily non-exhaustive — we're describing the category of features and their design logic, not providing implementation code.
Income features
The simplest income feature is average monthly deposits from identified income sources. More predictive: income stability ratio (standard deviation of monthly income / mean monthly income over the lookback window). A ratio below 0.2 indicates very consistent income. Above 0.6 indicates high variability. The interaction between income variability and income level matters: high income + high variability (gig worker earning $6K/month but inconsistently) has a different risk profile than low income + low variability (W-2 employee earning $2.8K consistently).
Obligation consistency features
For each identified recurring obligation, the key features are: (1) payment rate — how often in the lookback period was the payment made when expected?, (2) days delta — on average, how many days before or after the due date is the payment made?, and (3) payment gap rate — were there any complete misses in the window?
These features require identifying the expected payment cadence first, which requires detecting the recurring pattern in raw transactions before you can evaluate consistency against it. This is a non-trivial time-series problem and is where many naive implementations lose precision.
Balance behavior features
Minimum balance in the 7 days preceding each identified income deposit is a strong indicator of financial cushion. An applicant who regularly dips below $50 before their paycheck arrives is showing different financial management behavior than one who maintains $400 minimum before deposit. The slope of average monthly end-of-period balance over 24 months — positive, flat, or declining — is one of the highest-weight single features in our model on thin-file populations.
Data quality gates
Feeding poor-quality transaction data into a credit model is worse than having no data. Specific conditions that should trigger data rejection or flagging before features are computed:
- Account with fewer than 20 transactions per month over the lookback window — insufficient activity to derive reliable patterns
- Gap in transaction history of more than 45 days — account may have been dormant, switching banks, or the aggregator connection dropped
- More than one account connected but with overlapping transaction amounts — possible duplicate account or account consolidation mid-period that distorts income calculations
- Category confidence below threshold on more than 40% of transactions — categorization quality is too low to trust obligation features
Applications that fail data quality gates should fall back to human review or be declined with an appropriate adverse action code, not be forced through a model that will produce unreliable outputs on garbage inputs.
Latency requirements for real-time decisioning
For point-of-sale credit decisions, total decision latency matters. The bank data retrieval step is typically the longest single component — 1.5 to 4 seconds depending on the aggregator, the institution, and the depth of history requested. Feature computation on a 24-month transaction set of 2,000–3,000 records is computationally cheap on modern infrastructure: under 100ms. Model inference adds another 20–50ms. Total system latency from bank connection success to decision returned should be achievable under 5 seconds, which is acceptable for digital application flows but requires optimization to get there reliably.
Pre-fetching transaction data during the application form-filling step — starting the aggregator call as soon as the applicant authorizes account connection rather than waiting for form submission — is the most impactful latency optimization. Done correctly, the aggregator response arrives before the applicant finishes the remaining form fields, and the feature computation and model inference complete in the gap between form submission and the decision display screen.
The technical architecture matters. Cash-flow underwriting is not a drop-in replacement for a bureau API call. It requires a different integration design, different data quality logic, and a different applicant experience flow. Lenders who treat it as a simple swap typically end up with higher latency and lower data quality than those who build the integration around the data characteristics.
