Lending & credit
Origination, decisioning and servicing built on credit policy your team owns
We build lending systems where credit policy lives in a versioned decision service, applications are assembled from data rather than typed twice, and reason codes come out of the scoring model with the decision. Servicing and collections run on the same account record origination created, through the final payment.
Where it fits
The problem
Applications arrive as PDFs, and underwriters re-key income and employment into three systems before they touch the credit decision. The scorecard sits in a spreadsheet one analyst maintains. Adverse action letters are drafted by hand, so the stated reason can drift from what the model actually weighted.
What we build
We build a decision service with versioned policy, a rule engine credit officers can read, and scoring that returns ranked reason codes alongside the outcome. Document ingestion parses income and identity data into structured fields. Each decision is stored with the inputs, policy version and model version that produced it.
How we engage
Senior engineers sit with your credit and compliance teams, because policy questions decide the architecture. Work lands in your cloud and your repositories, with model documentation written as the model is built. Your analysts get tooling to change a cutoff and see the effect before it goes live.
What we build
Six pieces of work that most lending programs need in some order.
Application and origination
One application record collects applicant data, documents and third-party pulls, with the state machine visible to the branch and the call center. Parsed documents fill income, employment and identity fields, so underwriters stop re-keying the same pay stub into a loan system, a CRM and a spreadsheet.
Automated decisioning
Policy rules live in a versioned decision service with a test harness, so credit can change a debt-to-income cutoff in a sandbox and replay last quarter's applications against it. Champion and challenger policies run side by side, and each outcome records the policy version that produced it.
Explainable risk scoring
Scores return feature contributions and ranked reason codes in the same response as the decision, so the reason on the letter traces back to the model. Monitoring watches score drift and approval rates by segment, which gives fair-lending review something to read other than a developer's memory.
Adverse action and disclosures
Declines generate ECOA and Reg B adverse action notices from the recorded reason codes, with FCRA disclosures attached where a consumer report was used. Letter templates are versioned with the policy, and the audit view shows what was sent, when, and which data drove it.
Servicing and collections
Amortization, payment allocation, fees, hardship plans and restructures run against the same account the decision created. Collections work queues are driven by risk and promise-to-pay history rather than a nightly print-out, so agents stop calling borrowers who paid earlier in the week.
Alternative-data underwriting
Bank transaction feeds, rent and payroll data get turned into cash-flow features, with consent recorded per source. Thin-file applicants who had no score are assessed on income stability and balance volatility, and the feature definitions are documented for fair-lending review and FCRA obligations.
What an explainable decline looks like in production
The applicant sees a reason, the underwriter sees the policy version, and the examiner sees the inputs that produced both.
How we work
Discover
Systems, constraints, and the regulation you operate under get mapped before implementation starts, so the design accounts for what already runs and for what examiners will ask about.
Architect
A design that fits your stack. Integration-first, self-hostable, and built to change as rules, regulation, and volume do.
Build
Senior engineers ship in tight increments, each tested and reviewed as it goes, so the system is reviewable at every step instead of only at the end.
Harden
Security, compliance, and load-testing run inside the build, so controls, audit trails, and peak-volume behavior are proven before launch.
Run
The handover includes clean, documented systems, with the option to keep the same engineers operating them once they are live.
Why Oxagile
Decisions you can defend
A decision is stored with its inputs, policy version, model version and reason codes, so a question from an examiner or a customer gets answered from the record. Reconstructing a decision out of log files and an analyst's recollection is where lending programs lose arguments they should win.
Credit policy stays with credit
Rules read like credit policy and change through a review workflow with a sandbox and replay, so engineering is not the gatekeeper for a cutoff change. Where policy changes need an engineering release, teams batch them for months and let stale cutoffs run in the meantime.
Servicing designed with origination
The same account record carries the loan through disbursement, payments, hardship and payoff, so servicing does not start with a data migration out of the origination system. Collections sees the underwriting reasons, and portfolio reporting stops depending on a nightly file nobody owns.
Questions
How do we keep an automated decision defensible under ECOA and Reg B?
The decision service records inputs, policy version, model version and ranked reason codes for each application, and the adverse action notice is generated from those codes rather than a separate mapping table maintained by hand. Your compliance team owns the policy and the letter language. We build the mechanics and the audit trail they review.
Can we use machine learning models and still pass fair-lending review?
Many lenders do, under conditions their compliance function sets. In practice that means reason codes mapped to model features, documented feature definitions, disparate impact testing on candidate models, and monitoring of approval rates and score distributions by segment after launch. We build those artifacts as part of the model work rather than after it.
Do you replace our origination system or build around it?
Either. A common shape keeps the system of record and moves decisioning out of it, because that is where policy lag hurts most. We put a decision service in front, integrate through its APIs or a message queue, and migrate screens later if the case holds up. Replacing the whole stack makes sense when the vendor contract is ending or its data model blocks the products you want to sell.
What does alternative data require before we can underwrite on it?
Consent captured per data source and stored with the application, a documented feature set your credit team can read, and treatment of the data under FCRA where it comes from a consumer reporting agency. Adverse action reasons have to reference the alternative features in language an applicant understands. Disparate impact testing applies the same way.
Underwrite faster,
without the manual read.
Bring us the bottleneck, whether it is decisioning, document processing or servicing, and we'll scope the system that clears it.