.png)
Most AI pitches to bank and insurance boards sound similar. There’s the model, the platform, and then a few architecture slides. A better question is much simpler: show us something that’s already working for a client. What changed in their day-to-day work to make that happen?
Why does one examined outcome tell a board more than a highlight reel?
Every pitch talks about faster processing, lower costs, and better compliance. Those promises are easy to make, but much harder to check before a contract is signed. Even an impressive statistic can leave out the day-to-day details that determine whether the same result can be repeated inside a specific institution. Looking closely at one real result brings those details out. The most useful thing a board can ask is simple, what changed in the way the team worked to produce this result? If the vendor cannot show what changed and why it worked, the board has reason to question the result.
What changed underneath the 18-months-to-8-weeks result?
Consider a purchase-order approval process at a financial services enterprise. It spent 18 months stuck in proof-of-concept work, then went live in 8 weeks as a governed agent on SAP and Workday once the right foundation was in place. The results: 70% of routine approvals handled by AI, compliance reporting time down 30%, and a regulatory audit passed. Three operating model decisions made those numbers possible. Policy-as-code replaced approval rules that had previously lived in people’s heads. A clear human checkpoint was added for anything above a defined risk threshold. A complete audit trail captured every action from the agent’s first day in production, helping the process pass the audit.
A board considering a similar investment should ask whether its own institution has these three pieces or is ready to build them. Each one requires specific work.
What does policy-as-code involve in practice?
Policy-as-code starts with an inventory of every rule that governs a purchase order: the delegation-of-authority matrix, budget availability, segregation of duties between requester and approver, the vendor’s onboarding and due diligence status, and its third-party risk tier. Some of these rules are written into policy documents. Others exist only in email threads and in the judgement of experienced approvers. Each rule needs three things: a named owner, a written version an agent can execute, and a test.
The most practical test is a backtest. Run the encoded rules against the last 12 months of purchase orders, then compare the results with what people decided. Each mismatch exposes a gap in the rule or an inconsistency in past practice. Both need resolving before go-live.
Where should the human checkpoint sit?
Policy-as-code starts with an inventory of every rule that governs a purchase order: the delegation-of-authority matrix, budget availability, segregation of duties between requester and approver, the vendor’s onboarding and due diligence status, and its third-party risk tier. Some of these rules are written into policy documents. Others exist only in email threads and in the judgement of experienced approvers. Each rule needs three things: a named owner, a written version an agent can execute, and a test.
The most practical test is backtest. Run the encoded rules against the last 12 months of purchase orders, then compare the results with what people decided. Each mismatch exposes a gap in the rule or an inconsistency in past practice. Both need resolving before go-live.
What should the audit trail capture from day one?
The audit trail needs to be designed before the first transaction happens. Every decision made by the agent should capture the data it used, the version of the rule it applied, the decision itself, the reviewer’s identity if someone was involved, and a timestamp, with all of it stored so it cannot be changed later. Rule versioning is especially important. If an examiner reviews an approval from March, they need to see the rules that were in place at that time. The agent should also be included in the institution’s model inventory, with a named owner and a validation record, so model risk teams can track it alongside credit and pricing models.
Which approvals should go first?
Sequencing holds the three together. Renewals with already-approved, low-risk vendors have the clearest rules and the smallest downside, which makes them the right first lane. New categories follow once backtest agreement and override rates are stable, with one executive accountable across procurement, risk, compliance, and IT.
What should the board ask the vendor?
These points lead to some straightforward questions for any vendor: show us the rules behind the result, explain how the checkpoint threshold works, and show us an example of the audit record. The board can then ask its own leadership whether the same pieces are already in place internally. If they are not, a vendor’s result is a weak indicator of what the institution can achieve, no matter how similar the technology sounds. US banking regulators’ 2023 interagency guidance on third-party relationships already expects boards to oversee the risks that come with relying on vendors. An AI vendor whose claims cannot be traced back to a clear mechanism is difficult to oversee. The technology matters, but the out
come depends on the operating model built around it.
Before comparing vendor proof points, a financial services institution needs to understand what would have to change internally to achieve a similar result. Parkar’s AI Readiness Assessment identifies those gaps in 5 days, with no commitment to continue.