When treasury teams evaluate how they want to connect their cash management platform to their banks, the conversation usually starts with a capability question: can we get same-day balances, or are we stuck with yesterday's numbers? The answer depends almost entirely on which connectivity method the bank supports and which your treasury infrastructure is built to consume. Bank API feeds and traditional SFTP/BAI2 file delivery are not equivalent alternatives — they represent fundamentally different operating rhythms, and the choice between them affects everything from forecast accuracy to the operational window for sweep decisions.
How Traditional SFTP/BAI2 Delivery Works
The BAI2 format is the long-standing industry standard for bank account data delivery in the US, defined by the Bank Administration Institute. A BAI2 file contains transaction-level detail and summary-level balance information for a bank account over a specified period — typically the prior business day. Banks deliver these files to treasury via SFTP (Secure File Transfer Protocol) on a defined schedule, usually between midnight and 6:00 AM for the prior-day file.
SWIFT MT940 and MT942 message formats serve the equivalent function for international bank accounts. MT940 is the end-of-day statement; MT942 is an intraday statement that some banks deliver multiple times per day. A treasury team with international banking relationships typically receives a combination of BAI2 (domestic) and MT940/MT942 (international) files, which need to be parsed, normalized, and integrated into a coherent position.
The limitations of file-based delivery are predictable. The data is definitionally backward-looking — the best-case prior-day file reflects the account state as of the prior close. Intraday MT942 updates improve the picture but are delivered on fixed schedules (often two or three times daily) rather than on-demand. For treasury teams whose accuracy requirement is the prior-day opening balance, BAI2 SFTP is functionally adequate. For teams that need intraday position visibility — particularly those making same-day funding decisions — the lag is a structural constraint.
How Bank API Connectivity Works
Bank direct APIs — typically RESTful JSON endpoints using OAuth 2.0 or similar authentication — allow treasury platforms to query balance and transaction data on demand, in real time or near-real time. The query returns the current account balance along with pending transactions that have been authorized but not yet settled, providing a materially more current position than the prior-day BAI2.
The practical availability of bank APIs varies. Large US commercial banks have invested significantly in API infrastructure, with well-developed connectivity options for corporate clients. Regional banks vary — some have modern API platforms, others rely on SFTP-only delivery for corporate account data. International banks are similarly uneven, with European banks generally further along on Open Banking API standards (driven by PSD2/PSD3 regulatory requirements) than counterparts in other regions.
Connectivity options in the US commercial banking space, in order of real-time capability: direct bank API (highest freshness, typically 15-minute to real-time polling), intraday MT942/BAI2 intraday files (3-4 times daily), prior-day BAI2/MT940 (morning delivery, prior-day data), and bank portal screen scraping (least reliable, brittle, generally not suitable for production treasury use).
What "Same-Day" Data Actually Changes
The operational value of same-day bank data is not primarily about the treasury dashboard showing a current number. It's about the decisions that current number enables.
Consider a growing manufacturer with eight entities and a daily interco sweep assessment at noon. With prior-day BAI2 data, the noon position shows yesterday's closing balances — but by noon today, three ACH credits have posted that weren't visible in the file, and one large vendor payment has debited. The treasurer is making a sweep decision based on a position that's already $1.8M different from reality. With intraday API data refreshed at 10:00 AM, that $1.8M difference is already captured in the position before the noon decision point.
For companies with days cash on hand in the 15-25 day range — not unusual for mid-market industrials with seasonal working capital swings — a $1.8M positional error on a $12M average cash balance is meaningful. It can be the difference between a sweep that's correctly sized and one that leaves an entity short the following day.
We're not saying prior-day BAI2 is unusable. For companies where cash positions are stable and sweep decisions are made at a weekly cadence rather than daily, prior-day data is entirely adequate. The real-time argument is strongest for companies with tight operating cash, multiple entities, and daily funding decisions. At that level of complexity, position accuracy at the time of decision is directly tied to decision quality.
Implementation Realities: What to Expect
Setting up bank API connectivity is more involved than subscribing to a SaaS product. The process typically requires:
- Completing the bank's treasury API onboarding, which includes identity verification, account authorization (which accounts are included in the feed), and authentication credential issuance
- Agreeing to the bank's data use terms — most US commercial banks have specific data licensing terms for corporate API consumers
- Testing the integration in the bank's sandbox environment before production connection
- Establishing monitoring for API rate limits and error handling (production bank APIs have rate limits, and a treasury platform polling 20 accounts every 15 minutes across multiple banks needs to manage those budgets)
SFTP/BAI2 setup is more standardized — file format, delivery schedule, SFTP credentials — but still requires a bank contact, a testing period, and monitoring for file delivery failures. Missing a BAI2 file and not catching it until the next morning means operating on a 48-hour-old position.
Which Banks Support Which — a Framework for Assessment
Rather than naming specific banks and their current API capabilities (which change), the useful framework for evaluating your banking relationships is to ask three questions during annual bank reviews: Does the bank support intraday balance and transaction data delivery via API or intraday file? What is the typical delivery latency (real-time vs. 15-minute polling vs. 4x daily files)? What is the process for onboarding a treasury platform as an API consumer?
Banks that actively compete for corporate cash management business — particularly those pursuing mid-market commercial relationships — typically have strong answers to these questions. Regional banks focused primarily on lending may have less developed treasury connectivity infrastructure. That infrastructure gap is worth pricing into the banking relationship evaluation, particularly as real-time cash visibility becomes an operational expectation rather than a premium capability.
The bottom line for treasury teams building or upgrading their bank connectivity stack: prioritize API connectivity for your primary operating accounts and high-volume entities, accept SFTP/BAI2 for lower-volume entities or banks without API programs, and build your treasury infrastructure to handle both formats with consistent normalization. The goal is a single position view with consistent timestamps — not a mixed-latency picture that requires manual reconciliation of which accounts are as-of-now and which are as-of-yesterday.