Lending and payment AI agents, with credit, fair-lending and payment controls designed in.

By designing the controls in before the agent exists. Credit policy, fair-lending rules and payment limits are written as policy that every action the agent proposes is checked against, the agent works under its own identity and Unity Catalog permissions, and each decision is recorded with the policy version that made it.

The same checks run in testing and in production, so what risk approved is what ships. AutoFabric works this way for auto lenders, the Field Guide's chapter on governed actions sets out the pattern, and our AI agent services build it into yours.

In this sector they are the same problem. TILA, ECOA and FCRA checks are built into AutoFabric at /products/autofabric as policy the agent is evaluated against on every action, rather than sampled in a quarterly review. We build the system so your compliance people can prove what happened.

The SWBC work at /case-studies/swbc was built for credit unions specifically, and the constraint there was loan officers who needed to move faster without a training manual open beside them. Smaller institutions tend to have clearer problems and shorter decision paths, which suits how we work.

Yes. We'd land origination, servicing and CRM data under Unity Catalog, with lineage an examiner can follow from the report back to the source column. We moved Location Services' platform off Synapse and SQL Server onto Databricks in reversible waves, and AutoFabric's lending agents run on Unity Catalog and Databricks Apps.

Yes, and it is the more common shape. The Auto Approve engine at /case-studies/auto-approve sat in front of existing workflows rather than replacing them, and AutoFabric reaches into DealerTrack, RouteOne and CDK because that is where the deals already are.

Not as models. SR 26-2, which the Federal Reserve, the OCC and the FDIC issued on 17 April 2026 to replace SR 11-7, leaves generative and agentic AI out of its scope and says a bank's own risk management should set the controls for them.

Statistical models and non-generative AI, such as a scorecard or a pricing model, stay inside it. We'd keep both kinds in one inventory anyway, each with its owner, its data and its last validation, because an examiner asking about an agent will ask the same questions.

Under Regulation B the applicant hears within 30 days of a completed application, with the specific principal reasons for the decision, and Regulation B says a reference to internal standards or policies isn't enough.

So the reasons have to be stored with the decision when it's made. We'd write each decision and its reason codes to a governed table the notice is generated from, so the letter and the record can't disagree.

We build the data side of them. FinCEN's customer due diligence rule has covered institutions identify and verify customers and the beneficial owners of companies, build a risk profile and monitor for suspicious activity.

The screening and verification vendors stay where they are, and we'd land their results beside the account and transaction data under Unity Catalog, so an alert can be traced to the records behind it and every read of them is recorded.