Do lenders and payment companies build governance into an AI agent from its first design, or build the agent and work out the controls once it runs? Customers weighing agents for lending and payments ask us that. We answered it in AutoFabric, the auto lending platform we built on Databricks, by making every step an action whose permissions and policies are part of its definition. No agent can call a step that has none.
That choice decides more than the architecture. It decides when risk and compliance first see the work, and whether an examiner's question nine months later takes a query or a project to answer. An AutoFabric customer confirmed a 40% efficiency gain on the platform as a whole.
Why controls added after the build fail in lending
Two rules make the timing hard to fake. Under Regulation B, a declined applicant hears within 30 days, with the specific principal reasons for the decision, and a reference to internal policy isn't accepted as one. Those reasons have to be stored with the decision when it's made. An agent built first and governed later has already made decisions whose reasons nobody wrote down.
The second is SR 26-2, which the Federal Reserve, the OCC and the FDIC issued on 17 April 2026 to replace SR 11-7. It covers scorecards, pricing models and other non-generative AI, and it leaves generative and agentic AI out of its scope, saying a bank's own risk management should set the controls for them. For an agent, that means no supervisory template arrives to fill in later. The institution writes the controls itself, and the cheapest time to write them is before the agent exists.
There's a plainer reason as well. A check able to refuse an action is worth more than a report describing one after it funded. A control added after the build tends to become a report, because by then the agent's actions are already wired straight to the systems they change.
How AutoFabric puts the control inside each action
Every step of a loan file in AutoFabric is an action in one catalog, the same catalog its MCP server exposes to outside agents, with entries such as lending.evaluate_lender_eligibility or lending.contact_borrower_for_missing_data. Each entry carries a JSON Schema for its parameters, the permissions it needs, the policies it runs and the events it emits. An action can't be added without saying what it's allowed to touch, so the governance question gets asked when the step is designed.
The operator screens, our own agents and any outside agent all call the same invokeAction() path into a Temporal workflow. The state-machine guards, the policy evaluations and the idempotency keys are the same whoever made the call. An Open Policy Agent policy engine gates every action, with TILA, ECOA and FCRA checks built in as policy the agent is measured against, and every successful call writes an ActionInvocation row with the agent as the actor.
An agent also gets stricter preconditions than a person on the same action. When an agent asks for lender eligibility, it may use only a credit pull bound to this application, not simulated, no more than 30 days old and backed by an active FCRA authorization. Without one, the agent gets an error and the deal waits for current evidence.
Two of AutoFabric's rules are written in code that no prompt reaches. Lender eligibility is a rules check that returns written reasons, in the form "LTV 131.0% exceeds maximum 125%", so the answer to why a lender never saw a deal is a list of sentences. When the composer agent sends from the follow-up mailbox, which skips the platform's approval step, it may send only a fixed, reviewed template, and a free-form draft goes to a person instead. A model upgrade or a cleverer prompt can't change either rule.
Which team owns which control
Putting the control inside the action also gives each team something of its own to own, which is the part of the question about collaboration. In AutoFabric each kind of control sits in a different place. Lender tiers, with their credit score, LTV, DTI and mileage limits, are data, so a credit manager can change a tier without touching a prompt. Compliance rules are policy in the OPA engine. Scopes are a list on the agent's credential, such as lending.* or the single action lending.accept_offer. Where a regulation or the lender's credit policy reserves a call for a person, the file reaches that person carrying the reason, the rule and the record.
On a lender's own team we'd give each of those an owner before any agent is written:
- Product decides which actions an agent may take at all, and those become the glob list on its credential.
- Risk and compliance write the policies each action runs and sign off the reasons it records.
- Credit owns the eligibility tables the rules read.
- Engineering builds the catalog, the workflows and the grants, and can't ship an action that lacks a policy.
- Operations owns the approval steps and the queue a held file lands in.
Risk then reviews an action definition, a schema and a policy someone can read in one sitting, before any agent can call it. When compliance changes a rule, it changes a policy, and every caller of that action is held to the new one on its next call.
Testing an agent before it can change anything
For a lender adding agents to a live operation, we'd expose the read tools before any action that changes something. In our server a query tool and a mutating action are already separate tools, and each tool's description says whether it mutates state, so the first agent can read cases for a month while processors compare its reading with what they did. Where a decision model makes a judgement call, such as whether a refinance package is ready to submit, we'd run it in shadow mode beside the processing team for two weeks and study the disagreements.
Every call gets logged on both sides, request state, typed answer, confidence, model and version, to one Delta table. Joined to the lender's outcome on application ID, that log shows whether a high-confidence answer is usually right on your own files, which is the evidence risk needs before an agent is allowed to act unattended.
What Databricks holds once the agent is live
AutoFabric runs on Databricks: Unity Catalog holds the governed data and the permissions the agents inherit, Mosaic AI serves the models, the operator screens are Databricks Apps in the workspace, and Temporal carries the long-running steps. For a financial institution building its own agents, we'd put the controls in the platform the data team already governs.
Unity Catalog treats models, tools, MCP servers and agents as securable objects, with the same privileges and attribute-based policies already used for data. We'd run an agent as the user who asked, so it can reach only what that person could reach and the audit trail names a person. Unity Gateway routes every model and MCP request, applies rate limits and budgets, and records usage, and an input policy on an MCP service can require a person's approval before a call goes through. Statistical models and agents would sit in one inventory, each with its owner, its data and its last validation, because an examiner asking about an agent will ask the same questions SR 26-2 asks about a model.
A payments agent fits the same pattern. Say a payments company wants an agent that issues refunds on disputed transactions. We'd make the refund an action with a schema, a scope, a policy for the amount and the account, and a required idempotency key, run it inside a durable workflow so a crash between approval and payout can't send the money twice, and hold anything above a set amount for a person. The customer due diligence and transaction data the policy reads would land under Unity Catalog, so an alert can be traced to the records behind it.
Where we'd start with a lending or payments team
Pick one agent whose actions carry a regulatory consequence, a borrower message or a refund, and before anyone writes code, have product, risk, compliance and operations write its control list as action definitions: what it may call, which policy each call runs, what reason it records and who approves the exceptions. Then run it read-only beside the people who do that work today, and let it act only once the decision log says it agrees with them. Our financial services work and AI agents work pages cover how we build the rest, and the AI Readiness Assessment is where we'd name that first agent with you.
Frequently asked questions
Does SR 26-2 apply to the AI agents a lender builds?
Not as models. SR 26-2 covers statistical models and non-generative AI, such as a scorecard or a pricing model, and leaves generative and agentic AI to the bank's own risk management. We'd still keep agents in the same inventory as models, with an owner and a last validation date, because the examiner's questions about an agent are the same ones.
Does an AI agent make the credit decision in AutoFabric?
No. The agents prepare the file, chase stipulations and draft messages, and lender eligibility is a rules check that returns written reasons. Where policy reserves a decision for a person, the action waits for an approval, and the approval is recorded like any other action.
How long should a lending agent run read-only before it takes actions?
Long enough for the decision log to show it agrees with your processors on your own files. We'd plan on about a month of read-only work for a first agent, and two weeks of shadow mode for a single judgement call such as a readiness check, then decide from the disagreements rather than the calendar.
Can a payments agent use the same controls as a lending agent?
Yes, with more weight on idempotency. A repeated borrower message is embarrassing, but a repeated payout is a loss, so every money-moving action would require an idempotency key and run in a durable workflow that records the approval and the payment as one history.