Can we change the weights?

You should. The weights here reflect a lender whose main risk is servicing a growing book; yours may be migration risk, or data residency, or collections depth. Change them before you see any vendor scores, and write down why. Weights adjusted after the scores are in are no longer weights, they are justification.

Why is AI loan servicing only five percent when AI is the headline everywhere?

Because the categories above it are what makes AI safe to run at all. An agent operating on a ledger you cannot audit, in a tenant model you cannot isolate, is a liability rather than a capability. Five percent scores the AI itself; the governance that decides whether you can use it is scored under security, audit and architecture.

What total score should disqualify a vendor?

No total, on its own. A weighted total hides the shape of the result, and a vendor can reach a respectable aggregate while scoring near zero on something structural. Set minimum thresholds per category first, on the three or four categories you cannot compromise, and let the total rank only the vendors that clear all of them.

How do we stop the scorecard becoming a formality that ratifies a decision already made?

Score independently before the group meets, and keep the individual sheets. When the evaluators disagree by more than two points on a category, that gap is the most informative thing in the exercise: it usually means the requirement was never defined clearly. Discuss the spread rather than averaging it away.

Who should fill this in?

At least three people with different exposure: someone accountable for operations, someone accountable for technology, and someone accountable for risk or compliance. A scorecard completed by one function reliably scores that function’s concerns and under-weights everything else, which is how organisations end up with software that satisfies procurement and frustrates operations.

← Back to the RFP toolkit

LoktaRevised 2026-10-09

Loan management system vendor scorecard

A weighted scoring model for shortlisting enterprise Loan Management System vendors. Eleven categories, weights summing to 100%, blank columns for buyer scoring across up to three vendors. There is no separate file: print this page as PDF to circulate it.

Contents 3 sections

How to score

Score each category 0-10 for each vendor. Multiply by the category weight, sum across categories. Highest weighted total wins the shortlist; tied scores escalate to deployment posture and AI governance.

Distribute the scorecard to evaluation committee members before the vendor demo.
Each evaluator scores 0-10 per category for each vendor in scope.
Compute weighted score per vendor: sum of (raw × weight ÷ 10).
Aggregate evaluator scores via the mean: flag categories with high variance for re-discussion.
Cross-reference top three categories against the corresponding RFP response sections.

Category weights

Weights total 100%. Tune within ±2 percentage points to reflect lender-specific priorities; if you change the weights, re-balance to keep the total at 100%.

Category	Weight	Vendor 1	Vendor 2	Vendor 3
Loan servicing depthLifecycle, restructure, write-off, asset classification, customer servicing.	15%
Product configurabilityMulti-product, multi-currency, configurable rates, charges, allocation rules without code changes.	12%
Repayment, charges, allocationEMI, non-EMI, moratorium, custom allocation strategies, waivers, reversals.	10%
Collections & delinquency workflowsDPD calculation, bucket movement, follow-up allocation, promises-to-pay, settlements.	10%
Accounting & reconciliationGL mapping, accounting events, reversals, payment-gateway and bank reconciliation.	10%
Security, IAM, audit, complianceIAM, RBAC, maker-checker, structured audit, PII encryption, tenant isolation, mTLS.	12%
Integration architecture & APIsOpenAPI 3.1, versioning, KYC / credit / payment / core-banking / accounting connectors.	8%
Reporting & dashboardsPortfolio MIS, collections MIS, operational dashboards, configurable reports.	7%
Deployment & data residencyOn-prem, single-tenant cloud, customer VPC, per-region tenant pinning.	6%
Migration & implementation approachSix-phase methodology with parallel run, daily reconciliation, go / no-go gates.	5%
AI loan servicing capabilityLending-aware agent, governed actions, audit trail, RBAC-scoped permissions.	5%
Weighted total	100%

Notes

Use this space to record evaluation discussion, dissenting opinions, or follow-up questions for the vendor.

Frequently asked questions

How evaluation committees get the most out of a weighted scorecard, and the ways scoring most often goes wrong.

Can we change the weights?
You should. The weights here reflect a lender whose main risk is servicing a growing book; yours may be migration risk, or data residency, or collections depth. Change them before you see any vendor scores, and write down why. Weights adjusted after the scores are in are no longer weights, they are justification.
Why is AI loan servicing only five percent when AI is the headline everywhere?
Because the categories above it are what makes AI safe to run at all. An agent operating on a ledger you cannot audit, in a tenant model you cannot isolate, is a liability rather than a capability. Five percent scores the AI itself; the governance that decides whether you can use it is scored under security, audit and architecture.
What total score should disqualify a vendor?
No total, on its own. A weighted total hides the shape of the result, and a vendor can reach a respectable aggregate while scoring near zero on something structural. Set minimum thresholds per category first, on the three or four categories you cannot compromise, and let the total rank only the vendors that clear all of them.
How do we stop the scorecard becoming a formality that ratifies a decision already made?
Score independently before the group meets, and keep the individual sheets. When the evaluators disagree by more than two points on a category, that gap is the most informative thing in the exercise: it usually means the requirement was never defined clearly. Discuss the spread rather than averaging it away.
Who should fill this in?
At least three people with different exposure: someone accountable for operations, someone accountable for technology, and someone accountable for risk or compliance. A scorecard completed by one function reliably scores that function’s concerns and under-weights everything else, which is how organisations end up with software that satisfies procurement and frustrates operations.