Plaid vs Direct Host-to-Host: How Your Bank Feed Actually Gets to Your Software

Where a bank supports it, you authenticate directly with your own bank through an interface the bank controls, and the aggregator receives a token rather than your actual password. Where a bank hasn't built that kind of connection, some aggregators still rely on stored credentials behind the scenes to pull data on your behalf, which is a meaningfully different risk profile even though the end result looks identical in your software. Refresh timing also varies: some connections update close to real time through a webhook, while others refresh on a periodic schedule that can lag by hours.

A host-to-host connection is a scheduled file transfer, typically set up directly with your bank's treasury services team rather than through a consumer-facing connect flow. Files move on a set schedule, often once or twice a day, encrypted in transit and frequently using a separate encryption layer on the file itself. There's no real-time refresh here by design; you're trading immediacy for a connection that your own IT team can configure, monitor, and control end to end.

It's tempting to assume one of these two approaches is inherently more secure than the other, but that's not really the distinguishing factor. The real tradeoff is latency, an API connection can approach real time where the bank supports it, while a batch file always waits for its next scheduled delivery, and control, a host-to-host setup usually sits under your own team's keys and configuration, while an aggregator connection depends on that aggregator's own security practices and incident history.

Ask your vendor directly whether your specific bank connects through token-based authentication or a stored-credential method, since the answer can differ bank by bank even within the same software product. Ask how data is encrypted both at rest and in transit, and ask what happens to your historical data if you ever disconnect the integration: is it deleted promptly, or retained indefinitely on the vendor's side. These are reasonable questions for any vendor to answer clearly, and hesitation to answer them plainly is itself worth noting.

Put these questions to your software vendor:

• Does your specific bank connect through token-based authentication or a stored-credential method, since the answer can differ bank by bank?
• How is your bank data encrypted both at rest on the vendor's systems and in transit between the systems?
• What happens to your historical data if you ever disconnect the integration?
• How often does the feed actually refresh for your bank, given that near real time can mean hourly in practice?

If you need broad reach across many banking relationships with a fast setup, an aggregator is usually the practical choice, and it's what most small business software defaults to for exactly that reason. If you have a small number of large bank relationships and a genuine security or compliance requirement to control the connection directly, a host-to-host setup is worth the extra implementation effort, even though it takes longer to stand up and typically needs your bank's treasury services team involved from the start.

A company that started with an aggregator connection because it was fast to implement doesn't have to rip it out the moment it adds a bigger bank relationship or a compliance requirement. Many treasury and accounting platforms support both connection types side by side, so you can move your highest-volume or most sensitive accounts to a host-to-host connection while leaving smaller, lower-risk accounts on the aggregator feed. Reassess this mix whenever you add a new bank relationship rather than assuming your original setup still fits every account equally well.

This is also worth revisiting the first time a customer, auditor, or investor asks a specific question about how your bank data moves. Having a clear, current answer ready, rather than needing to go find out, is usually a better use of the review than waiting for the question to force it.