How a one-person data team at Keep built real-time banking infrastructure on dbt

At a dbt Summit 2026 breakout session on using dbt as production banking infrastructure, Scott Ziolko, head of data at Keep, described how his one-person data team took credit underwriting from a one-business-day, manual, spreadsheet-driven process to decisions delivered in under 60 seconds, around the clock.

Keep is a fintech serving Canadian small businesses with banking, credit cards, credit limits, and capital loans. Ziolko said the company has served around 5,000 small businesses, processed more than $1 billion in card transaction volume, and issued hundreds of millions of dollars in capital loans.

Keep has no dedicated data platform team or on-call rotation; Ziolko is the data team, supported informally by a handful of data-literate engineers and an underwriting team of seven. That constraint, he said, shaped nearly every architecture decision that followed.

The underwriting process previously ran on a folder of spreadsheets, one file per company, complete with the inevitable "copy of copy of" version sprawl. Someone would manually download banking CSVs, manipulate spreadsheets, and turn around a decision within a business day, with nothing processing on nights, weekends, or holidays.

That process got Keep to 5,000 businesses but, in Ziolko's telling, couldn't get the company to the next 5,000 or 10,000, and couldn't support embedding lending into partner products. Every decision also lived in its own file, making it effectively impossible to analyze trends across the full portfolio.

Rather than build and maintain hard infrastructure problems himself, Ziolko chose to buy solutions for real-time data movement, orchestration, and always-on compute, so he could spend his limited time on Keep's actual credit and risk logic. That strategy produced a three-tool stack: Artie for real-time change data capture, Snowflake for orchestration and compute, and dbt for model governance.

Ziolko framed the modeling decision as a trade-off between real-time, simple, and observable: batch dbt models are simple and observable but not real-time, while hand-rolled streaming is real-time but far from simple. He accepted some loss of observability in exchange for real-time processing, landing on dbt, Snowflake dynamic tables, and Artie.

On the business-interface side, he weighed flexible-but-ungoverned spreadsheets against fully custom, tightly governed software, and chose a middle point built on Streamlit and Snowflake. He noted that AI tooling is starting to ease that particular trade-off, though it wasn't central to this build.

Artie handles real-time CDC out of Postgres and MongoDB into Snowflake at sub-second latency, giving Ziolko both an exact replica of production data and a full change history for time travel. He said he turned it on, has barely had to look at it since, and it's also used elsewhere in Keep's production systems, including real-time accounting.

Snowflake dynamic tables, streams, and tasks trigger processing the moment new data lands, which Ziolko said is what makes sub-minute latency possible without a hand-built streaming system. dbt handles model governance and versioning on top, including the hourly and snapshot-based models that don't need real-time treatment.

A new customer's data flows in through Flinks, a Canadian bank-data service Ziolko compared to Plaid in the US, which pulls six to twelve months of banking history into MongoDB as a JSON document. Artie replicates that into Snowflake in under a second, and Snowflake streams and tasks flatten the JSON into materialized tables before dbt models compute cash flow and risk features.

dbt models specifically handle deduplication, since customers sometimes reconnect their bank accounts multiple times or get re-underwritten on overlapping six-month lookback windows, and Ziolko said dbt is well suited to defining what counts as a single, unique transaction. Underwriting outputs then flow back into the warehouse, where dbt views and materializations support fast downstream queries before a compliance review signs off, particularly for new customers whose personal and business accounts need to be untangled.

The pipeline's real-time components, the Snowflake streams and tasks and a stored procedure that loops over unsatisfied underwriting requests, trade away much of dbt's usual observability, and Ziolko said failures there tend to be silent. He offset that with custom dbt freshness tests, including one that ignores weekends and Canadian holidays so the team isn't alerted for expected pauses in processing.

Ziolko was careful to define what "one-minute latency" actually covers: the external Flinks bank connection itself can take up to 30 minutes, though 95 percent of the time it resolves in under five, and only the Snowflake-triggered processing after data arrives lands reliably under a minute. He argued that once real-time infrastructure is in place, latency stops being an engineering constraint and becomes a business cost and vendor choice, letting Keep dial speed up or down by use case, such as pulling credit reports only twice a day to save cost.

Every underwriting calculation is stored alongside the git hash of the code version that produced it, giving Keep full traceability and letting Ziolko reprocess the entire portfolio against a new risk model with a single line of SQL. dbt documentation is also pushed to Notion and made available through MCP so the rest of the company can find model definitions without asking him directly.

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →