Credit decisioning is the step where a lender turns an application and the data attached to it into an outcome: approve, decline, or refer to a person. It covers the rules that get applied, the data those rules run against, and the record the decision leaves behind. It is not the whole lending process — intake happens before it and funding after — but it is the point where a lender's credit policy is either applied consistently or is not.
Three Outcomes, Not Two
Most definitions of credit decisioning stop at approve or decline. In practice the third outcome does most of the work.
A system that can only say yes or no has to force every marginal file into one of those answers. Either the threshold sits loose enough that files which deserved a look get approved, or tight enough that files which would have performed get declined. Neither is a policy choice. Both are artefacts of a process with nowhere to put uncertainty.
Refer is where the uncertainty goes. It means the file did not cleanly satisfy the rules and a person needs to see it, with the rule that failed and the data that was missing already attached. Thin files, irregular income, and documented policy exceptions belong there. The argument for automating the other two outcomes is mostly that it stops straightforward applications queueing behind the hard ones.
This is also the part that gets lost when decisioning is described as a speed feature. The applications a lender most wants to handle well are the ones that do not fit the rules, and those are exactly the ones automation should hand to a human rather than resolve on its own.
Four data sources feed the policy layer. A decision is only as defensible as the weakest one underneath it.
What the Decision Actually Runs On
Four kinds of data usually sit behind a credit decision.
The application itself — amount, term, purpose, stated income, and whatever the product requires. This is the only input the applicant controls directly, which is why it is also the one most worth verifying against something else.
The credit file. A bureau report from Experian, Equifax, or TransUnion, pulled under a permissible purpose. What the rules take from it varies: a score, specific tradeline behaviour, derogatory marks, inquiry velocity, or some combination.
Bank and cash-flow data. Verified deposit and transaction history, increasingly through an aggregator. For thin-file and near-prime applicants this is often the input that makes a decision possible at all, because the credit file alone does not say enough.
Identity and watchlist screening. Identity verification and sanctions screening. The sequencing here matters more than lenders tend to assume: screening belongs before the credit decision, not after it, because a match is not a credit outcome and should not be handled as one.
A decision is only as good as the weakest of these. Most of the decisioning failures worth worrying about are not bad rules — they are good rules applied to a stale credit file, or to an application whose income was never checked against anything.
Decisioning, Underwriting, and Origination
These three get used interchangeably, and the imprecision causes real confusion when lenders compare systems.
Origination is the whole lifecycle: intake, documents, decision, funding, servicing. A loan origination system manages that end to end.
Credit decisioning is one step inside it — the evaluation that produces the outcome. It applies across products and covers decisions on existing accounts, not just new applications.
Underwriting usually names the same step, with a stronger connotation of human judgment applied to a new application. In most lenders' systems, automated underwriting and automated credit decisioning describe the same engine.
The practical test is what a vendor replaces. A decisioning engine does not replace an origination system; it decides inside one. If a product claims to do both, it is worth asking which of your existing systems is meant to be retired.
The same application down two paths. The difference that holds up under examination is consistency, not speed.
What Automation Actually Changes
The gain lenders expect from automated credit decisioning is speed. The gain that matters under examination is consistency.
When policy lives in a spreadsheet, a procedures document, or an experienced underwriter's judgment, it is applied slightly differently every time — not through carelessness, but because that is what interpretation does. Two comparable applications can receive different answers, and no one can say precisely why, because the reasoning was never written down in a form that can be compared.
A configured rule set removes that variance by construction. The same thresholds run against every file. When the policy changes, the change is deliberate, dated, and attributable to someone. That is a fair-lending argument as much as an efficiency one: the claim that comparable applicants were treated comparably is much easier to make when the same versioned rule set produced both answers.
Speed follows from this, but it is the second-order benefit. A lender that automates an inconsistent policy has made the inconsistency faster.
The Decision Has to Survive Being Questioned
Whatever produces the outcome, the lender still owes the applicant an explanation.
Under Regulation B, a creditor acting on a completed application has 30 days to notify the applicant. Where the action is adverse, the notice must either state the specific reasons or tell the applicant they can request those reasons within 60 days (12 CFR 1002.9). The Fair Credit Reporting Act adds its own duties when the decision was based in whole or in part on a consumer report (15 U.S.C. § 1681m).
The word doing the work is specific. A notice saying the application did not meet the lender's credit standards is not a statement of reasons. And the CFPB has addressed the obvious objection directly: in Circular 2022-03, it confirmed that creditors using complex algorithms must still provide specific reasons, and that the difficulty of explaining a model is not a defence for failing to. A lender that cannot say why a model declined someone has a compliance problem, not a technology limitation.
This is the practical case for rules and scorecards a credit team can read. An outcome that resolves to named reason codes produces the adverse action notice almost directly. An opaque score does not, and the gap has to be filled by hand on every file.
Each outcome carries an obligation. The decline is the one with a statutory clock attached.
What the Record Has to Contain
The test for a credit decisioning process is narrow, and it is worth applying to your own: can someone who was not involved reconstruct a decision from the record alone, months later?
That usually requires the rule version that was in force, the data the rules ran against, the score or outcome produced, the reason codes behind any adverse action, and a timestamp. Rule version rather than rule matters more than it sounds — a decision made in March under thresholds that changed in June cannot be assessed against June's policy, and a system that only stores current rules quietly makes every historical decision unexplainable.
Regulation B sets the retention floor: 25 months for consumer credit and 12 months for business credit, measured from the date the applicant was notified (12 CFR 1002.12). Institutions handling customer financial information also have obligations under the GLBA Safeguards Rule (16 CFR Part 314) covering access controls, encryption, and logging — which is a reason to hold this evidence in fewer systems rather than more.
Reconstructing a decision means retrieving the version of the policy that produced it, not the current one.
Where the Process Usually Breaks
Three failures account for most of what goes wrong, and none of them is a bad credit call.
The data and the decision live in different systems. A report is pulled in a portal, read, and the outcome typed into the CRM. The decision is recorded; the evidence behind it is not. This is the most common one, and it only becomes visible when someone asks what the file looked like at the time.
The policy is not versioned. Thresholds change, nobody records when, and a decision from two quarters ago can no longer be assessed against the policy that actually produced it.
Referrals have no structure. Files route to a human without the failing rule attached, so the underwriter restarts the assessment rather than resolving the exception. The automation saved nothing; it moved the queue.
Each of these is a records problem rather than a judgment problem. The lenders who come through examinations well are generally not the ones making better credit calls — they are the ones whose credit calls leave a trace without anyone having to remember to create one.
Keeping the Decision and Its Evidence Together
The structural fix is unglamorous: decide where the data already is.
LASER DECIDE runs credit decisioning inside Salesforce, on the same record the application and the pulled credit data sit on. Rules and scorecards are configured rather than coded, every change is versioned, and each adjudication records the rule version, inputs, score, reason codes, and timestamp as part of making the decision rather than as a reporting exercise afterwards. Referrals carry the rule that failed, so the underwriter starts from the exception. Credit decisioning software for Salesforce lenders covers how that works in practice, and the DECIDE engine sits inside the wider platform alongside ACCESS, which retrieves the credit file, and COMPLY, which turns the reason codes into the notice.
For the wider workflow view — how retrieval, decisioning, and compliance fit together in one environment — see credit reports, decisioning and compliance in Salesforce. If the immediate problem is elapsed time rather than defensibility, where loan approval delays actually come from is the more useful starting point.
Sources
- Regulation B, Notifications — 12 CFR 1002.9, Electronic Code of Federal Regulations
- Regulation B, Record retention — 12 CFR 1002.12, Electronic Code of Federal Regulations
- Consumer Financial Protection Bureau, Circular 2022-03: Adverse action notification requirements in connection with credit decisions based on complex algorithms, 26 May 2022
- Fair Credit Reporting Act, Requirements on users of consumer reports — 15 U.S.C. § 1681m
- GLBA Safeguards Rule, Standards for Safeguarding Customer Information — 16 CFR Part 314, Electronic Code of Federal Regulations
This article is general information about how credit decisioning works. It is not legal advice, and it does not replace your own compliance program or counsel.