Many engineering leaders I talk to aren't fully bought in on deploying AI agents in their enterprise yet. They understand what AI can do, but they won't deploy agents until they have full governance over their data. Our engineers built AutoFabric, where every credit pull, VIN decode, payoff quote and stipulation an agent runs for an auto lender is checked for TILA, ECOA and FCRA and recorded, on Unity Catalog and Databricks Apps. Those records reach lending.agent_actions, a Unity Catalog table, through gRPC. An AutoFabric customer confirmed a 40% efficiency gain. The rest of a loan's events usually reach the lakehouse overnight. Zerobus Ingest, generally available on Databricks since 23 February, gives them the same governed path into Delta tables within seconds, without a Kafka cluster in between. We'd start with the decision events behind a Regulation B notice.
We've built lending software from origination to recovery, including the repossession platform we moved off Synapse and SQL Server onto Databricks for Location Services, in waves that could each be rolled back, and the refinance approval engine at Auto Approve that replaced four or more manual workflows. Systems like those produce a loan's events, and when the events land overnight, a fraud check comparing applications across dealers runs on yesterday's applications.
Why loan events still arrive a day late
A single auto loan touches a lot of systems. The application lands from a dealer portal, the origination service pulls a bureau, a decision comes back with reason codes, the loan funds, and then servicing takes over with payments posted, payments missed, and sometimes a recovery. Each of those is an event, and each lives in a different system.
The standard way to move events like these into an analytics platform is a message bus, usually Kafka, with connectors on both ends. That works. It's also a platform of its own, with brokers, topics, schemas, connector upgrades and someone on call when a consumer falls behind. A national bank runs that team. A mid-size lender, a credit union or an auto finance company usually doesn't, so the events get written to the operational database and copied into the warehouse overnight.
The cost of the overnight copy shows up when an examiner asks why a loan was priced the way it was. The answer has to be rebuilt from a nightly snapshot instead of read from the event that drove it.
What Zerobus Ingest writes, and how fast
Zerobus Ingest is a serverless endpoint in Lakeflow Connect that takes records from an application over gRPC or REST and writes them straight into a Unity Catalog managed Delta table. There's no bus to run in between, and every write is governed by Unity Catalog like any other table.
For a lender, the useful facts are in Databricks' quotas and concepts pages. A record is acknowledged once it's durable, and it becomes queryable shortly after, typically within seconds. A single stream carries up to 100 MB a second, a table takes up to 10 GB a second, and a record can be up to 10 MB, which is far more than any loan event needs. The SDKs cover Python, Java, Rust, Go and TypeScript, so an origination service written in any of the usual languages can send events from the code that makes the decision.
The sign-in model is the part a security team will ask about first. Clients use short-lived OAuth tokens through a service principal, or exchange a token from an identity provider such as Microsoft Entra ID, so no long-lived Databricks secret sits on the application server. A lender already running on Entra keeps one identity story from the origination app to the table.
Databricks documents a rescue column for fields that don't fit the table schema, so when the origination service adds a field, the rescue column is the first place we'd look. Zerobus Ingest usage is recorded in Databricks system tables, and that's where we'd read the cost at the end of a pilot.
An auto lender's application, from dealer to decision table
Take an auto lender that buys contracts from a few hundred dealers. A dealer submits an application through RouteOne or DealerTrack, and the lender's origination service takes it from there.
The origination service sends four events per application through the Zerobus SDK: submitted, bureau pulled, decisioned and funded. The decisioned event carries the decision, the inputs it was made on and its reason codes. All four land in a raw Delta table under Unity Catalog within seconds of happening.
A Lakeflow pipeline reads that raw table, drops duplicates on application ID plus event ID, and writes a clean decision table. Three things read from it. The adverse action letter is generated from the decisioned row, so the reasons on the letter are the reasons recorded with the decision. A fraud check looks for the same SSN or the same VIN arriving from several dealers within minutes, which is a pattern a nightly load can only report after the contracts have been bought. And the portfolio dashboards show today's approvals and funding as they happen.
Payments follow the same shape once the loan is in servicing, and an early-delinquency model can score a missed payment the same day.
Duplicates, ordering and the decision record
Zerobus delivers at least once.
If a connection drops before the acknowledgment comes back, the SDK reconnects and replays the records it hasn't heard back about, so the same event can land twice. For a loan that's fine as long as the pipeline expects it. We'd give every event an ID at the source and dedupe on application ID plus event ID before anything reads the data, because a duplicated funded event in a dashboard is a funded loan counted twice.
Ordering holds within one stream and nowhere else.
Databricks' concepts page says records are committed in the order they're enqueued on a single stream, and that there's no global ordering across streams. So we'd keep every event for one application on one stream, and never write logic that assumes a decisioned event from one stream lands after a submitted event from another. Where order matters for a rule, the pipeline sorts on the event's own timestamp.
Regulation B gives a declined applicant the specific principal reasons within 30 days, and a reference to internal policy doesn't count. If the reason codes are written as part of the decisioned event, the letter and the audit read the same row. When an examiner asks about a loan from last spring, the answer is a query on a governed table with lineage back to the event, and nobody has to rebuild it from four systems.
Where we'd keep Kafka, CDC or batch
Zerobus is a write path into a table. When several services need to react to the same event, such as a funded loan that has to reach the servicing platform, the dealer funding system and the GL, a message bus is still the right tool, and we'd keep it. Change data capture is another case. If the events already live as rows in the loan origination system's database and nobody wants to touch the application, Lakeflow Connect's database connectors read the changes without a code change, which is less work than adding an SDK to software the lender doesn't own.
We'd also keep anything that needs ordering across streams on a system built for it, and we'd never put Zerobus in the path of authorizing a payment. A few seconds to queryable is fast for analytics and far too slow for a decision a borrower is waiting on at checkout. The authorization happens in the operational system, and the event about it goes through Zerobus afterwards.
Run one stream beside the batch for a month
We'd start with decision events, because they carry the most regulatory weight and the smallest volume. The origination service sends them through Zerobus while the nightly load keeps running, and for a month both feed the same reports. At the end, compare three numbers: how old the data was when the fraud check read it, what the stream cost in the system tables against the batch job's compute, and how many duplicates the pipeline removed. If the freshness is worth the cost, payments go next, then dealer-portal activity and collateral telematics.
The first thing to do this week is list the events your origination service already writes to its own database, and mark the ones a fraud check or an adverse action letter reads the next morning. Those marked events are the first stream. If you'd like engineers who have built lending systems and Databricks pipelines to run the month beside your batch, our Databricks data engineering team can start from that list and your origination service.
Frequently asked questions
What is Databricks Zerobus Ingest?
Zerobus Ingest is a serverless service in Lakeflow Connect that writes records from an application directly into Unity Catalog managed Delta tables over gRPC or REST. It became generally available on 23 February 2026, with SDKs for Python, Java, Rust, Go and TypeScript. Records are acknowledged once durable and are typically queryable within seconds.
Does Zerobus Ingest replace Kafka for a lender?
For events whose only destination is the lakehouse, it can, and that removes a platform most mid-size lenders would rather not run. Where several services consume the same event, such as a funded loan that servicing, dealer funding and the GL all need, we'd keep a message bus. The two can run side by side.
Does Zerobus Ingest deliver each record exactly once?
No. Databricks documents at-least-once delivery when the client retries records that weren't acknowledged, which the SDK does by default. We'd give each event an ID at the source and dedupe on application ID plus event ID in a Lakeflow pipeline before anything reads it.
Can Zerobus Ingest feed adverse action notices?
It can carry the decision event the notice is built from. If the decisioned event includes the inputs and the reason codes, a governed decision table can generate the Regulation B letter, so the letter and the record can't disagree. The notice itself is still produced by the lender's own process.