Credit Decisioning Software: Why Your Credit Policy Should Never Live in a Vendor's Code
Updated: 1 day ago
When a regulator asks why a credit decision was made, it doesn't ask the vendor. It asks the institution.
The institution is accountable for its credit policy: the criteria, thresholds and exceptions that determine who receives credit, how much, and on what terms. Yet in many institutions, that policy doesn't fully belong to them. Part of it is configured inside a vendor's system by the vendor's consultants. Part is hard-coded in software no one in the credit team can read. Part lives in spreadsheets and documents that don't match what the system actually does.
This is one of the least discussed risks in credit decisioning software, and one of the most consequential. An institution that doesn't control its policy can't change it quickly, can't prove what it was at any given moment, and can't leave its vendor without rebuilding it from scratch.
Where credit policy actually lives
Ask a credit director to show the institution's current credit policy and you'll typically get a document. Ask whether that document describes exactly what the system does today, and the honest answer is usually "approximately."
In practice, credit policy is spread across several places:
A policy document, approved by the credit committee, written in natural language.
A rules engine or decisioning platform, where someone translated the document into executable rules, sometimes years ago.
Code, where thresholds or exceptions were implemented directly by developers to meet a deadline.
Model configuration, where cutoffs and score bands were set by the data science team.
People's heads, where analysts apply informal criteria that were never written down.
Each translation between these layers introduces drift. Over time, the policy the institution approved and the policy the system executes diverge, and no one can say exactly where.
The cost of not owning your policy
When policy lives in a vendor's code or configuration, the institution pays in four ways.
Speed. Changing a threshold should take days. When it requires a change request to the vendor, a development cycle and a release window, it takes months. In a credit cycle, months are expensive.
Auditability. To reconstruct a decision made last year, the institution needs the exact policy that applied at that moment. If the policy history lives in the vendor's change logs, if it exists at all, the institution depends on the vendor to answer its own regulator.
Lock-in. A policy embedded in a vendor's proprietary format can't be moved. Changing vendors means rebuilding years of accumulated credit logic, so institutions stay with systems they would otherwise replace.
Accountability. When the people accountable for the policy can't read or change it directly, accountability becomes a formality. The credit committee approves a document. Someone else decides what the system does.
Two models of policy, and why one is consultancy
There are two broad ways to handle credit policy in decisioning software.
In the first model, the vendor writes the rules. The institution provides its manual. The vendor's team translates it into the system. Every change goes back to the vendor. This is often presented as a service. In practice, it is consultancy with software attached: the institution's most important credit logic is maintained by people outside the institution, in a format the institution doesn't control.
In the second model, the vendor provides the instrument and the institution writes the policy. The credit team defines, tests and publishes policy directly, in an explicit and readable form. The vendor's software executes it, records it and makes it auditable, but never owns it.
Only the second model is compatible with institutional accountability. It is also the only one that scales: an institution whose policy changes require a vendor's time can't adapt faster than its vendor's backlog.
Extraction proposes, humans decide
Modern tools can help institutions build explicit policy faster. Language models can read a policy manual and propose candidate rules. Analytics can mine historical decisions and suggest the thresholds that were actually applied. Both are useful.
But both produce proposals, not policy. A rule extracted automatically from a document may misread an exception. A threshold inferred from history may encode a bias the institution never intended. That's why one principle is non-negotiable: no rule enters production by automatic inference. Every published policy is a human act of approval, recorded as a decision in its own right.
Extraction proposes. The accountable owner reviews, tests and approves. The approval itself, who approved what and when, becomes part of the record.
What policy ownership means in practice
Owning credit policy isn't a matter of contract language. It shows up in six concrete capabilities:
Explicit. The policy is written in a form that people accountable for it can read and verify, not only in code.
Versioned. Every change creates a new version. Previous versions remain on record, with who approved them and when.
Testable. Before a new version is published, it can be simulated against historical decisions: which outcomes would change, in which segments, with what expected effect.
Published by the institution. The credit team publishes changes itself, without depending on the vendor's release cycle.
Traceable. Every decision records the exact policy version that produced it, so any decision can be reconstructed under the rules that applied at the time.
Portable. The policy can be exported in a readable, structured format. If the institution changes systems, its credit logic goes with it.
Where the vendor's ownership ends
Policy ownership doesn't mean the vendor gives up its own intellectual property. A clear boundary serves both sides:
The vendor owns the instrument: the decision engines, the architecture, the software that evaluates, records and certifies decisions.
The institution owns the policy and its decisions: the criteria, the thresholds, the exceptions, every version and every decision record produced under them.
That boundary should be explicit in the contract and in the architecture. A vendor that blurs it, by embedding the institution's logic in its own proprietary structures, is creating lock-in, whether it intends to or not.
Questions to ask any credit decisioning software vendor
Can our credit team read the full policy the system is executing, without asking you?
Can we change a threshold and publish it ourselves, today?
Is every policy version stored, with who approved it and when?
Can we simulate a policy change against our historical decisions before publishing it?
Does every decision record the exact policy version that produced it?
If an AI tool proposes a rule, does it require explicit human approval before going live?
Can we export our policy in a readable format if we change vendors?
Where exactly does your intellectual property end and ours begin?
If the answers are vague, the institution is not buying a decisioning system. It is outsourcing its credit policy.
Accountability requires control
Credit decisioning software should make institutions faster, more consistent and more auditable. It can only do that if the institution remains in control of the one thing it is accountable for: its policy.
The policy belongs to the institution. Technology provides the instrument. The institution defines, tests, publishes and audits its own rules.
Want to see what full ownership of your credit policy looks like in practice? Talk to our team →
Comments