Credit policy audit checklist: 25 questions to answer before the exam
The 25 questions an audit — internal or regulatory — asks of automated credit decisions, grouped by area, with the evidence a good answer should show.
Updated July 2026 · 6 min read
In short
Twenty-five questions an audit asks of automated decisioning, across five areas: governance and roles, changes and versions, data and providers, models, and evidence. Each one should be answered with a link to the evidence, not with a yes.
When an audit arrives — internal, external or from the regulator — the questions about automated decisioning are fairly predictable. This checklist anticipates them: 25 questions organized by area, designed to be answered with evidence rather than narrative. If any of them has no demonstrable answer today, that is where the work is.
Written byMariano Sokal · COO at uFlow
COO at uFlow. Works with banks, fintechs and retailers across Latin America on how credit policies are governed: who decides, how a change is controlled, and what evidence remains for audit and the regulator.
Governance and roles
The first thing an auditor looks at is who can do what:
- Is there an explicit list of who can edit, approve and publish each policy?
- Are designing and publishing separate permissions in the system (segregation of duties), or just a good-faith convention?
- Do users with access to the engine have two-factor authentication enabled?
- What happens when someone with access leaves the organization — is there a revocation procedure, and is it actually followed?
- Do the systems that execute policies via API have their own identity (one credential per system) and least-privilege permissions?
Changes and versions
The second round of questions targets the change cycle:
- Can you reconstruct which version of each policy was live on any past date?
- Does every change record who made it and when?
- Is there evidence of pre-production testing (test cases, flow debugging) for material changes?
- Were substantive changes validated with controlled experimentation (champion/challenger testing) before being rolled out broadly?
- Is there a rollback procedure that has been tested — not just documented — for changes with unwanted results?
Data and providers
Third area: where the data that decides comes from:
- Which external sources take part in each decision, and with which credentials are they queried — are those credentials outside the code, in a secrets store?
- Is the original (raw) response from each provider queried retained and linked to the decision?
- What happens when a source does not respond: is there a fallback path defined in the policy, and evidence that it has been used?
- Is there monitoring of availability and error rate per provider?
- Does the use of the data subject's information have the consent regulation requires, and can that consent be demonstrated?
Models
If there is in-house scoring or ML, the audit goes deeper:
- Is there an inventory of the models in production, with version, date and owner?
- Can you determine which model version took part in each individual decision?
- Is there drift monitoring — periodic comparison of current performance against expected performance?
- Are outcomes analyzed by segment to detect bias (approval and delinquency rates by group)?
- Does the model output pass through explicit rules before becoming a decision, or does it decide on its own?
Evidence and monitoring
The closing area: the ability to demonstrate, case by case and in aggregate:
- Is any individual decision reconstructable: inputs, rules applied, version, path taken and outcome?
- Is a customer complaint answered with evidence from the transaction, under a defined procedure?
- Is there an operations dashboard — volumes, approval rates, errors — and someone who actually watches it?
- Do sharp shifts in the approval rate trigger a review (an early signal of a data or rules problem)?
- Is the decision record retained for as long as applicable regulation requires, and can it be exported for the auditor's analysis?
Technical documentation
How this is implemented in the engine, step by step.
Common questions
How many of these questions does the engine answer on its own?+
Almost all the evidence ones: versioning, transactions, raw responses, permissions and segregation of duties come built into uFlow. The process ones — who approves, how often it is reviewed, which regulation applies — belong to the institution: the engine supplies the evidence; the team defines the governance.
What is the best way to use this checklist?+
As a quarterly self-assessment: each question is answered with a link to the evidence, not with a "yes". The ones left without demonstrable evidence become next quarter's governance backlog — far cheaper to resolve before the exam than during it.
Related topics
Decision traceability and audit: how to explain every credit decision
Every credit decision should be explainable: what data came in, which rules ran, why it was approved or declined. End-to-end audit traceability.
ObservabilityMonitoring credit decisions in production: transactions, errors and raw responses
What to watch once a policy is live: searching transactions by ID, date or variable, analyzing errors, and reaching each provider's original response.
ProductHow the uFlow decision engine does it
Governance, versioning and traceability built into the engine, without slowing the business down.
Explore all guides or read the glossary.
Would this work for your decisioning process?
Transform your credit assessment process with the decision engine.