Credit checks: the decision you have to explain

An automated credit check assesses whether a counterparty pays, then decides something somebody is owed an explanation for. Four arrangements, six dimensions, and where a model does not belong.

By the Foxnut team · Updated 11 August 2026

A credit check is two decisions wearing one name

A credit check assesses something and then decides something, and almost every disappointment with this software comes from automating the first and believing the second came with it. The assessment is a question about evidence: what the filings, the bureau file, the payment history and the references say about whether this counterparty pays. Assembling that evidence is a data-gathering job with a known answer, and automating it is uncontroversial and usually overdue. The decision is a different object. It is a limit, a set of terms, or a refusal, and it lands on a person or a company that in most jurisdictions is entitled to be told why. That entitlement is not a compliance footnote bolted onto the end. It is the constraint that decides which arrangements are available at all, because a system that cannot state the principal reason a decision went the way it did has not automated the decision. It has automated the part before it and left the explanation to whoever signs the letter. So the choice in front of a finance or credit team is not whether to automate the check. It is which of four arrangements it can live with, and how much of the decision it is prepared to hand to something that cannot account for itself. Foxnut Studios builds systems of this kind and hands them over, which is a reason to be direct about the standard this studio holds for systems that judge people before any of the four is chosen.

The four arrangements, and what each can say when asked why

What separates them is not accuracy. It is what each one can put in writing when the applicant, the regulator or the auditor asks what the decision rested on.

Axis	A person reads the file	A bought score with a policy cutoff	A rules engine on your own credit policy	A model fitted on your own outcomes
What it produces	A limit and terms, with a written rationale of variable depth	An approve, refer or decline against a threshold somebody set	A limit, a block or a hold, derived from stated rules over bureau and internal data	A probability of default or late payment for this counterparty
What evidence it uses	Everything available, including the things nobody wrote down	The bureau’s model, over the bureau’s data	The rules as configured, over whatever fields are populated	The company’s own history of who paid and who did not
What it can state as the principal reason	Whatever the person actually thought, if they recorded it	The vendor’s reason codes, which exist for this purpose	The rule that fired, which is the strongest position of the four	An attribution computed afterwards, which is not the same object as a reason
Where it breaks	Inconsistency between assessors, and a rationale nobody wrote down	A cutoff inherited from somewhere and never revisited against outcomes	Rule sprawl, and rules that stopped describing the policy years ago	Thin files, shifted behaviour, and a training set made only of the applicants who were approved
Who owns it after go-live	The credit controller, and nobody else	The vendor, with the threshold owned internally by default	The finance system administrator, if the rules were documented	The trained internal team the system was handed to

The third row is the one that decides most cases, and it is the row buyers examine last. Two of these four arrangements produce a reason as a by-product of how they work. One buys the reason from a vendor. One computes something afterwards that resembles a reason and is not the thing the obligation asks for.

What the decision turns on

Six structural dimensions decide whether a process is worth automating. Credit checking reads unusually on three of them: the exceptions are defined by absent evidence rather than by odd cases, the reversibility runs backwards from where intuition puts it, and the regulatory exposure is named in three legal systems at once rather than implied by any of them.

Credit checks: process profile
Dimension	What it reads on credit checks	Source
Exception variance	The exception is an absence of evidence, not an unusual case, and it is not randomly distributed. On the United States regulator's own corrected estimates, 5.8% of adults had no credit record at all in December 2010 and a further 12.7%, some 29.7 million people, held a record that a commercially available scoring model would not score. By December 2020 the share with no record had fallen to 2.7% and the scored share had risen from 81.6% to 87.5%, which still leaves roughly one adult in eight outside the reach of a score. Trade credit has the same shape for a different reason: a company incorporated last year has no filed accounts and no payment record to read.	CFPB, credit invisibles estimate update, June 2025
Volume	Not application count. What scales is the number of decisions that have to carry a stated reason, and the clock attached to each. Regulation B gives a creditor 30 days from a completed application to notify the applicant of the action taken and either to state the specific reasons or to disclose the right to obtain them. Business credit runs on a separate track keyed to size: an applicant with gross revenues of one million dollars or less is treated close to a consumer, while a larger applicant or one seeking trade credit is owed notice within a reasonable time and a written statement of reasons only on written request. The payback condition follows as a condition rather than a threshold: where one person can decide the month's applications and write each refusal's reason in a morning, the obligation is already being met and automation is buying speed, not defensibility.	12 CFR 1002.9, Regulation B
Cost of an error	Asymmetric, and paid in two different currencies. A wrong approval costs the exposure and the collections work behind it. A wrong refusal costs a customer and creates a regulatory event, because the reason given has to be the reason the decision actually rested on, and the United States regulator has stated that a creditor does not satisfy the requirement by checking the closest identifiable factor on a sample form. In the European Union the same class of failure is priced directly: breach of the AI Act's deployer obligations carries administrative fines of up to EUR 15 000 000 or 3% of total worldwide annual turnover, whichever is higher.	CFPB Circular 2022-03; Regulation (EU) 2024/1689, Article 99(4)
Reversibility	One-directional, and in the opposite direction to the intuition. A refusal is the reversible output: where a creditworthiness assessment involves automated processing, the recast European consumer credit rules give the applicant a right to obtain human intervention, to receive a clear and comprehensible explanation of the logic and its effects, to express a point of view and to request a review of the assessment and the decision. The approval is the one that sticks. The same article forbids a creditor from later cancelling or modifying the agreement to the consumer's detriment on the ground that the assessment was incorrectly conducted, except where the consumer knowingly withheld or falsified information.	Directive (EU) 2023/2225, Article 18(7) and 18(8)
Regulatory exposure	Named in three legal systems at once, and by process rather than by implication. Under the Equal Credit Opportunity Act and Regulation B a statement of reasons must be specific and indicate the principal reasons, and the United States regulator's position is that a creditor cannot justify noncompliance on the basis that the technology it uses to evaluate applications is too complicated or opaque to understand. In the European Union the Court of Justice ruled on 7 December 2023 that a credit agency's automated probability value about a person's ability to meet future payment commitments is itself automated individual decision-making under Article 22(1) of the GDPR, where a third party receiving it draws strongly on it. And the AI Act lists systems intended to evaluate the creditworthiness of natural persons or establish their credit score as high-risk, with a carve-out only for detecting financial fraud, and gives the affected person a right to clear and meaningful explanations of the role the system played.	CFPB Circular 2022-03; CJEU C-634/21; Regulation (EU) 2024/1689, Annex III point 5(b) and Article 86
Vendor market maturity	Mature, concentrated, and the concentration is itself the exposure. In the 2024 Bank of England and Financial Conduct Authority survey of United Kingdom financial services, 75% of firms were already using AI, a third of all AI use cases were third-party implementations against 17% two years earlier, and the top three providers accounted for 73%, 44% and 33% of reported cloud, model and data providers respectively. In the same survey 46% of firms reported only partial understanding of the AI technologies they use, which the report attributes largely to third-party models. No public measure of concentration in credit checking software specifically was retrieved, so none is quoted here.	Bank of England and FCA, AI in UK financial services, 2024

Two of those rows carry the argument. The regulatory row says the obligation attaches to the explanation rather than to the accuracy: no regulator named above asks whether the decision was correct, and all three ask what it rested on and whether the affected person can find that out. The vendor-maturity row says the market is moving in the opposite direction to that obligation. Third-party implementation has doubled in two years and nearly half of firms report only partial understanding of what they are running, which means the ordinary purchase in this category is a system whose reasoning the buyer cannot inspect and whose explanations the buyer is nonetheless answerable for.

The reversibility row is the quiet one and it sets the design. Automating an approval automates the output that cannot be recalled, while automating a refusal automates the output an applicant can force back into a human review. That is an argument for putting the automation weight on gathering, scoring and preparing the decision, and for keeping a person on the release rather than on the rejection, which is the reverse of how most of these systems are scoped.

When to choose each

Each arrangement wins a real category of company, and the order matters more than the sophistication of any one of them.

When a person reading the file wins

It wins where the book is small enough that the assessor knows the counterparties, where limits are reviewed on a cycle rather than on demand, and where a refusal is a conversation rather than a notice. The information that matters at that scale is relational, and no model has access to it. The failure mode is not slowness. It is that two assessors reach different answers on the same file, and that the rationale exists only for as long as the assessor does. The upgrade worth making is almost never a decisioning product. It is a written credit policy and a record of what each decision rested on, which is also the thing that has to exist before any of the other three arrangements can be built.

When a bought score with a policy cutoff wins

It wins in volume consumer or small-business lending, where the bureau has seen more of the applicant than the lender ever will and where the vendor’s reason codes are engineered for the notice the lender has to send. Buying that is sensible and building it is not. The failure mode is the threshold: it was set once, by someone who has left, against a portfolio that has since changed, and nothing in the arrangement forces a comparison between the cutoff and what actually happened to the accounts on either side of it. A score bought without a plan to back-test the cutoff against realised outcomes is a decision nobody owns.

When a rules engine on your own credit policy wins

It wins in trade credit, and it is the most under-used of the four. A limit derived from a stated rule over bureau data and the company’s own payment history produces its explanation as a by-product: the rule that fired is the reason, and it is legible to the credit controller, the auditor and the applicant without any further machinery. Most accounting packages and every serious ERP already carry a version of this, which is why the first question on a credit automation brief should be whether the existing credit block has ever been configured. The failure mode is sprawl: rules accumulate, exceptions are added for named accounts and never removed, and after three years the engine encodes a policy nobody has read. That is a maintenance problem with a known remedy, which is an annual read-through of the rule set against the written policy.

When a model fitted on your own outcomes wins

It wins where three conditions hold together: enough counterparties that behaviour is statistical rather than relational, enough repayment history per counterparty that a pattern exists to fit, and a decision record that captures why past applications went the way they did. The third condition is the one that fails quietly. A model trained only on accounts that were approved has never seen the outcome of the applications that were refused, so it learns the past policy as well as the past behaviour. The second failure mode is the one the regulators have already named: a probability of default is not a principal reason, and an attribution computed after the fact is an account of the model rather than an account of the decision. Where this arrangement earns its place, it earns it as an input to a stated rule, not as the rule.

What this comparison usually gets wrong

The first error is treating explainability as a property of the model rather than of the decision record. The obligation in every regime described above attaches to a specific decision about a specific person or company, and it asks what that decision rested on. A system that can produce a general account of how the model behaves, and cannot produce the reason this application was refused on this day, has answered a different question. The practical consequence is that the design work is in what gets written down at decision time, and it is cheap if it is designed in and expensive if it is retrofitted.

The second is assuming business credit sits outside the rules. It does not. Regulation B covers business credit with modified notification requirements rather than with an exemption, and the fork is the applicant’s size: at or below one million dollars of gross revenue in the prior fiscal year the treatment is close to consumer credit, and above it the creditor owes notice within a reasonable time and a written statement of reasons if the applicant asks in writing within 60 days. A trade credit team that has concluded none of this applies has usually concluded it about the wrong half of its own book.

The third is a sequencing error about the European rules, and it runs in both directions. The Court of Justice position is binding now: since December 2023, a credit agency’s automated probability value counts as automated individual decision-making under the GDPR where the recipient draws strongly on it, which reaches every lender using a bought score today. The AI Act’s high-risk obligations for creditworthiness systems are the ones that are not yet in force, applying from 2 December 2027 under the dates as amended in July 2026. Teams routinely over-prepare for the second and under-prepare for the first, because the second has a name everyone recognises.

The fourth is quoting a number the publisher has retracted. The most circulated statistic in this field is that 26 million Americans are credit invisible, which comes from a 2015 report and was corrected by its own author in June 2025 to 13.5 million for the same month, with an almost commensurate rise in the count of records that exist but cannot be scored. The correction matters for design and not only for accuracy: it moves the problem from people the system has never heard of to people the system has a file on and still cannot score, which is a different exception to handle and a different explanation to write.

There is one prior question this comparison does not answer and it belongs before the four arrangements rather than inside them. Whether the payment history, the counterparty master and the past decision records are complete, consistently coded and current enough for any of this is a readiness question with its own answer, and a decisioning system built on a ledger that records only what is outstanding will explain its decisions in terms of evidence it never actually had.

The verdict

The evidence supports automating a credit check thoroughly on the gathering and cautiously on the deciding, and the line between the two is sharp enough to write into a scope. Automate the collection without hesitation: bureau retrieval, filings, internal payment history, the counterparty record, the alerting when any of it moves. Automate the decision only to the depth at which the rule can be stated in a sentence the applicant would recognise. Treat a fitted probability as an input to that rule rather than as the rule, and do not buy a decisioning system at all until the credit policy it is meant to encode exists in writing.

The reason is structural rather than a matter of how good the models currently are. Three of the six dimensions point the same way. The regulatory row says the object of examination is the reason rather than the outcome, in three legal systems that agree on that point while disagreeing on almost everything else. The vendor-maturity row says the market is supplying more third-party opacity each year to buyers who remain answerable for the explanations, and that nearly half of firms already report only partial understanding of what they run. And the reversibility row says the irreversible output is the approval, while the contestable one is the refusal, so a system that automates the rejection and keeps a person on the release has the asymmetry the wrong way round. A process with that profile does not reward a more accurate score. It rewards a decision that can account for itself.

For a team weighing this, the useful first move is a measurement rather than a purchase. Take the last two years of credit decisions and try to reconstruct, for each refusal, the principal reason it rested on, from what was written down at the time. A team that can do that already has the credit policy an automated system would need to encode, and can tell which of the four arrangements it is actually choosing between. A team that cannot is being asked to buy an explanation engine for decisions it has never explained, and the reconstruction is a week’s work that will change the specification. Walk us through your last twenty refusals and we will tell you which of the four arrangements you actually need.

The part most pages leave out

When not to choose Foxnut Studios

Situations where another option is the better call, and where we say so in the first conversation rather than the fourth.

The decision is a regulated credit decision, and the proposed system is a model whose output cannot be reduced to the actual principal reasons the refusal rested on. The plan is to attach a plausible reason afterwards from a fixed list. The incumbent scorecard vendor, whose attestation is the product. A bought scorecard ships reason codes designed for exactly this notice, and the vendor stands behind the mapping from score to reason. The regulator's position is that model complexity is not a defence, so a system that cannot name its principal reasons has not saved the work of explaining a decision. It has moved that work to whoever signs the notice.
The counterparties are new entities or people with no filed accounts, no trade references and no payment record, and that is most of the book rather than a tail of it. A redesigned process, not an automated one. Where the record is absent there is nothing for a model to read, and the effective instruments are commercial rather than analytical: a deposit, a guarantee, a staged limit that opens as behaviour accumulates, a shorter first term. Automating a judgment about missing evidence produces a confident answer built from the same nothing a person was looking at.
The system would set a limit and release the credit with nobody reading the decision, on the reasoning that a human step is the bottleneck. A human control point, or a simpler deterministic rule. The asymmetry is in the law rather than in the model: under the recast European consumer credit rules a creditor cannot later cancel or modify an agreement to the consumer's detriment on the ground that the assessment was wrongly conducted, so an approval is the one output here that does not come back. Automating the gathering and leaving the release to a person is cheaper than either the exposure or the correction.
The accounting package or ERP already carries a credit check that blocks or holds an order against a limit, and it was never configured, or the bureau subscription already returns a recommended limit that nobody reads. That software, and the studio says so. Setting a credit limit field and switching on a block that is already licensed is configuration work, not a build. Paying for a custom system to produce a decision the incumbent already produces is the wrong purchase, and it is the most common thing found underneath a credit automation brief.
There are a few dozen trade counterparties, limits are reviewed once a year by a finance lead who knows every one of them, and a refusal is a conversation rather than a notice. The person already doing it, unchanged. At that size the decision quality comes from relationships and from the terms negotiated, not from the speed of the check, and the useful automation is a bureau alert when a counterparty's filings or payment behaviour move. Buying a decisioning system for a book one person holds in their head adds an explanation obligation without adding an explanation.

Sources

Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is what an AI engagement covers and what you keep.