AI lending demos are relatively easy to build.
Connect borrower data to a scoring model, display a risk score, add an LLM-generated explanation, and the prototype can look surprisingly complete.
Production is different.
A real lending system needs to survive incomplete bureau data, inconsistent borrower records, model drift, policy changes, human overrides, compliance reviews, disputes, legacy integrations, and infrastructure failures.
That difference between a working AI model and a working lending product is becoming one of the more interesting engineering problems in financial services.
This article is an independent analysis informed partly by GeekyAnts' recent guide on building AI lending products for production. The original article goes deeper into credit risk, compliance, auditability, core banking integration, and operational controls.
Rather than repeating the guide, this post looks at the engineering patterns behind the argument and five companies working around production AI in lending and financial services.
The Model Is Only One Component
A production lending platform might roughly follow this flow:
Borrower Application
↓
Identity / KYC / AML
↓
Document + Data Ingestion
↓
Credit Risk Model
↓
Credit Policy Engine
↓
Automated Decision / Human Review
↓
Reason Codes + Adverse Action
↓
LOS / Core Banking / CRM
↓
Monitoring + Audit Trail
The AI model is only one box.
That matters because many AI projects optimize the model while leaving everything around it under-engineered.
For example, imagine that a probability-of-default model returns a perfectly valid score. But the credit bureau API failed earlier and the model unknowingly scored an incomplete borrower profile.
Technically, the model worked.
Operationally, the lending system failed.
A production system instead needs to recognize that missing dependency, stop or downgrade automated decisioning, retry the provider, use an approved fallback, and route the application to an appropriate review queue.
That is much closer to distributed-systems engineering than a machine-learning experiment.
Credit Policy Should Sit Above the Model
One architectural idea from the GeekyAnts analysis is particularly important: the credit policy engine should remain authoritative over the AI model.
Think of the distinction this way:
AI model:
"What does the data suggest?"
Credit policy:
"What is the institution allowed and willing to do?"
Those are not the same question.
Suppose a model identifies a borrower as statistically low risk, but the application violates an institution's debt-to-income threshold or another lending rule.
The model should not quietly override policy.
Instead:
model_score = 0.82
policy_check = FAIL
decision = REFER_OR_DECLINE
log_conflict(model_score, policy_rule)
The policy decision should be deterministic, versioned, and auditable.
This separation also makes the system easier to maintain. Risk teams can modify lending rules without retraining the model, while model teams can improve predictive performance without silently altering institutional policy.
Explainability Needs to Produce Something Operational
AI lending discussions often stop at SHAP values, feature importance, or model interpretability dashboards.
Those tools are useful, but they do not solve the complete production requirement.
There are at least three different consumers of an explanation:
- Model validation teams need to understand model behavior.
- Compliance and audit teams need decision evidence.
- Borrowers may need understandable reasons for an adverse outcome.
A chart showing feature attribution is therefore not automatically a borrower-facing explanation.
The source article makes a useful distinction: if a lending model cannot eventually support the specific reason codes required by the decision workflow, explainability has not been fully implemented.
This changes the engineering question from:
"Can we explain the model?"
to:
"Can the complete system reconstruct why this specific application received this specific decision?"
That requires more than explainable ML.
It requires event logging.
Auditability Should Be Event-Driven
Consider storing a decision as a collection of immutable events:
{
"application_id": "APP-20481",
"model_version": "credit-risk-v4.2",
"score": 0.71,
"policy_version": "consumer-policy-2026-08",
"rules_triggered": ["DTI_THRESHOLD"],
"reviewer": "UW-184",
"final_decision": "declined",
"reason_code": "EXCESSIVE_DEBT_OBLIGATION"
}
The exact schema will differ between institutions, but the principle matters.
A lending organization should be able to reconstruct:
- what data entered the decision,
- which model version processed it,
- which rules executed,
- what score was produced,
- whether a human intervened,
- why the final outcome changed,
- and what explanation reached the borrower.
The original analysis argues that these controls should exist inside the architecture rather than being reconstructed later from multiple databases, spreadsheets, and people's memories.
That is an engineering decision, not just a compliance decision.
Human-in-the-Loop Does Not Mean "Review Everything"
Another common mistake is treating human review as binary.
Either AI makes the decision automatically or every application reaches an underwriter.
Neither approach uses automation particularly well.
A more practical architecture divides workflows by risk and confidence:
High confidence + low risk
AI + policy checks → automated workflow
Medium confidence or exceptions
AI recommendation → underwriter review → decision
High risk, dispute, or unusual case
mandatory human review → documented justification
The automation boundary can move as the organization gathers evidence about model performance.
This is similar to progressive automation elsewhere in software engineering: automate predictable paths first and keep uncertain states visible rather than pretending uncertainty does not exist.
Core Banking Integration Is Where the Prototype Meets Reality
Eventually, an approved application needs to become a real loan.
That usually involves some combination of:
- Loan Origination Systems
- Core Banking Systems
- CRM
- KYC/AML providers
- payment infrastructure
- document systems
- servicing platforms
- analytics environments
This is why a polished scoring dashboard alone is not a lending product.
The GeekyAnts article argues that core-system integration should be treated as a first-class architectural layer and recommends event-driven integration, access controls, reconciliation, retries, and observability around these connections.
For developers, this is probably the least glamorous part of AI lending.
It may also be the most important.
5 Companies Working on Production AI for Lending and Financial Services
Calling any single consultancy the "best" would be misleading because requirements vary enormously between a FinTech building a lending product and a global bank modernizing several decades of infrastructure.
These five are more useful to look at as examples of different approaches to the same production problem.
1. GeekyAnts
GeekyAnts approaches AI lending from a product-engineering perspective.
Its published architecture focuses on connecting risk models with document intelligence, lending policies, human-review workflows, LOS and core banking systems, monitoring, and audit trails rather than treating the model as a standalone product.
That approach is most relevant when a project requires both application engineering and AI integration.
The notable part is the emphasis on failure handling. Bureau outages, model-policy conflicts, drift, borrower disputes, and inconsistent system-of-record data are treated as architecture problems rather than unusual edge cases.
2. Thoughtworks
Thoughtworks has significant engineering experience around financial-services modernization and AI.
Its recent analysis of secured lending highlights fragmented back-end infrastructure, manual document processes, data fragmentation, and AI-enabled underwriting as major areas of change. It also discusses the regulatory implications of using AI for creditworthiness decisions.
Thoughtworks is particularly interesting for organizations where lending modernization is connected to larger data-platform, architecture, and legacy-transformation work.
3. Accenture
Accenture operates at a different scale and is more relevant to large financial institutions undertaking broad transformation programs.
Its work around underwriting copilots demonstrates an important production pattern: let AI extract documents, calculate or retrieve supporting information, check policy, and prepare analysis while preserving the human underwriter as the final decision-maker.
That pattern is useful beyond Accenture itself because it shows where LLMs can help without giving them unrestricted decision authority.
4. EPAM
EPAM's recent financial-services work concentrates heavily on moving AI from isolated experiments into enterprise-scale banking environments.
Its engineering roles and publications reference applied AI architecture across areas such as credit risk, fraud detection, regulatory reporting, responsible AI, cloud platforms, data infrastructure, and core banking.
EPAM is consequently more relevant when AI lending sits inside a larger banking platform or enterprise modernization program.
5. Globant
Globant combines financial-services engineering with AI-led modernization.
Its recent work argues that legacy cores, fragmented integrations, and insufficient data architecture are preventing banks from scaling agentic AI beyond pilots. Globant also has established digital-lending capabilities covering areas such as smart underwriting, risk monitoring, and collections.
That makes it another company worth examining when lending AI cannot be separated from legacy-system modernization.
What Should Developers Evaluate Before Shipping?
Regardless of who builds the system, these questions provide a useful production-readiness test:
- What happens when borrower data is incomplete?
- What happens when the bureau or KYC provider is unavailable?
- Can policy override the AI model deterministically?
- Can every decision be reconstructed?
- Can the system produce usable reason codes?
- Which decisions require human review?
- Who can override the model, and is that override recorded?
- Can a previous model version be restored?
- Is drift monitored against live lending outcomes?
- Can LOS, core banking, CRM, and servicing systems reconcile their state?
If the architecture has no clear answers, improving model accuracy probably is not the next priority.
Final Thought
The interesting thing about AI lending is that the hardest work increasingly happens outside the AI model.
Production readiness depends on data contracts, APIs, deterministic policy logic, observability, workflow orchestration, human-review systems, access controls, audit events, and failure recovery.
AI can certainly improve underwriting, document processing, risk analysis, fraud detection, and borrower operations.
But lending software cannot behave like a demo.
When real money and real credit decisions are involved, the important question is not whether the model can make a prediction.
It is whether the engineering system around that prediction knows when to trust it, when to question it, when to escalate it, and how to explain what happened afterward.
Top comments (0)