How to keep lender criteria current in loan product matching

1. Build a criteria register by lender, product, and effective date

Each row of the register holds one criterion and names the lender, the product, the rule, the source document, the section the rule sits in, and the date it took effect.

The matching agent checks each application against the rules in force on the application date, and superseded versions stay in the register with an end date. That's how a recommendation shows the source and date of every criterion it used: each match prints the lender, the document title, the version's effective date, and the section.

The common mistake is to keep only the current criteria and overwrite the old ones. Then a customer asks in June why they were matched to a product in February, and your team has no record of the rule that applied.

2. Load each new lender document as a new version

When a lender issues a new criteria guide, product guide, or bulletin, log it with its issue date and its effective date. Then extract the criteria it sets and compare them with the version in force. The result is a change list of criteria added, changed, and withdrawn, each tied to the section it came from. A named owner on your team approves the change list before the new version goes live, and you rerun any open match that relied on a changed criterion.

Keep the criteria in the register and out of the prompt. The matching agent's instructions tell it to apply the criteria in force on the application date. A new mortgage type then arrives as new rows with their own effective date, and the instructions stay as written. That matters because a rule written into a prompt has nothing that enforces it, and teams that patch new criteria into prompts end up checking every output by hand.

3. Set a source order for lender documents that disagree

A product guide and a later bulletin can state different limits for the same product, so write a source order in advance that decides which one the match uses:

• A dated criteria change outranks the guide it amends, for the products and dates it names.
• Between two documents of the same type, the later effective date applies from that date forward.
• A document issued by the lender outranks any summary of it, including a sourcing table or your team's own notes.
• When the scope of a change is unclear, or two documents with the same effective date conflict, the match is reserved for a human. The adviser confirms the reading with the lender.

Keep both documents in the register with their dates attached, so the conflict stays visible after it's resolved. Private equity teams face the same problem with reports that disagree.

4. Record which borrower facts each match used

Each borrower fact a match uses carries its value, the document it came from, the page or field, and that document's date. For a self-employed applicant, that means the trading start date from the filed accounts, the income figure from the accountant's letter, and the deposit amount from a named bank statement. The fact list tells the adviser what to check and the system what to rerun. When a borrower's income figure is revised, every match that used the old figure runs again against the same criteria version.

5. Give every match one of four outcomes

A match can end four ways: fulfilled with proof, refused by a rule, a named gap, or reserved for a human. It lands in exactly one and carries its proof, which makes it decision-grade.

• Fulfilled with proof. Every criterion passes, and the proof lists each one with its version and date. Beside each criterion sits the borrower fact that met it, with evidence pointing to the page in the borrower's documents.
• Refused by a rule. A criterion fails, and the refusal names the criterion, the lender document with its section, the borrower fact, and how far the fact falls short. That's what lets a broker explain an eligibility rule to a customer. In the worked example below, Lender B's refusal cites section 3.1 of their criteria guide, which requires 24 months of trading for self-employed applicants. The borrower's filed accounts show trading started 18 months before the match. The adviser can then tell the customer what changes the answer: six more months of trading.
• A named gap. A criterion needs a borrower fact the file lacks, so the match names the missing fact and the document that would supply it, and leaves the field empty for the borrower to fill.
• Reserved for a human. The case meets a trigger from step 6 and goes to a named adviser with the reason attached.

6. Decide in advance which matches go to an adviser

Write the triggers down before the first live run, so the agent reserves a case for a human on a stated rule. Useful triggers:

• Two lender documents conflict, and the source order from step 3 leaves the scope unclear.
• A borrower fact supports two readings, such as a contractor paid a day rate who also files company accounts.
• The lender's criterion leaves the call to the underwriter's discretion.

Each reserved case names the adviser, the trigger, and the documents involved, and the adviser's decision goes into the record. When that reading should apply to the next case like it, the adviser's correction is approved and becomes a rule in the register. The match tells the adviser which published criteria a product meets. The lender's underwriter makes the credit decision.

A worked example: one borrower, four lenders

Here is the method on a made-up borrower and four made-up lenders, where every name, date, section, and figure is invented.

Sam is self-employed, has traded for 18 months, and has one year of filed accounts. Sam wants to buy an apartment in a converted warehouse at 90% loan-to-value (LTV). The file holds the accounts, an accountant's letter, and the purchase contract, and nothing in it shows where the deposit comes from.

Lender A is the hard case. Under the first rule in step 3, the bulletin outranks the guide for the purchases it names. The conversion was completed this year, though, and the bulletin doesn't say whether a newly converted property counts as new build. Lender A's own guide lists conversions as a separate property type, so the source order leaves the scope unclear and the match goes to Sam's adviser, who asks Lender A's underwriting desk.

Say Lender A confirms that conversions count as new build under the bulletin. Then Sam's Lender A match changes to refused by a rule, citing the bulletin and the lender's confirmation. The approved correction becomes a rule, so the next conversion case with under 24 months of trading is capped at 85% without a trip to the adviser.

Sam's adviser now has a plain message: Lender D proceeds today, and Lender C proceeds once Sam sends the bank statement. Lender B becomes an option at 24 months of trading, six months from now, and Lender A caps Sam at 85% on this property.

Sam spends a month getting the bank statement so the adviser can compare Lender C. In that month, Lender D issues a new guide, effective 1 May, that raises their trading minimum to 24 months. Sam submits the Lender D application in May, so the application date falls under the May version and the change list from step 2 flags the match for a rerun. The rerun refuses the Lender D product, since Sam has 19 months of trading against the new 24. The register keeps the April version, so the earlier match still shows the rule it was made under.

Know when a retrieval chatbot is enough

Brokers can work with a retrieval chatbot when they ask about a lender document and check the passage themselves before anything reaches a customer. Lender B's minimum trading period for self-employed applicants is that kind of question.

A broker needs an enforceable matching workflow once the output becomes a recommendation to a customer, or when one check runs across many lenders every day as their criteria change. Retrieval ranks passages by how closely they match the question, so a superseded guide that matches well comes back beside the current one. The chatbot leaves the source order from step 3 to whoever reads the passages. An enforceable workflow applies the version in force on the application date and checks each criterion against the borrower facts. It returns one of the four outcomes with its record. For where that line sits in other workflows, see deterministic AI agents.

What to measure

Five measures show whether the register is keeping up with your lenders:

• Days from a lender document's issue date to its version going live in the register.
• The share of matches in each outcome, week by week. A rising share reserved for a human points to a trigger written too wide, or to a lender document the register has yet to absorb.
• Refusals that cite a superseded criteria version. The target is zero.
• Named gaps closed before the case goes to the lender.
• Refusals overturned on adviser review, where the borrower meets the criterion. Each one becomes an approved correction.

How Saphenia runs loan product matching

Saphenia runs loan product matching as one decision workflow, with its own decision logic, rules, and approved corrections. Saphenia reads your lender documents and writes down what the decision follows: the criteria, which document wins when two disagree, and where the thresholds sit. Every rule is versioned, and every fact carries the period in which it was valid, so a match can be reconstructed against the rules that held at the time.

Hard rules, such as a minimum trading period, pass or fail outright. Soft preferences, such as the order your firm presents products in, apply by default, and every override is recorded. Every claim in the agent's output is checked before the answer goes out. Each match lands in one of the four outcomes from step 5, with proof that carries the facts, the rule, its version, and the date. When two lender documents disagree, Saphenia holds them side by side with their dates and reports the contradiction. An adviser's correction becomes a rule that every later match follows once an expert approves it.

Saphenia builds the decision logic in days, and the first decision ships in weeks. Everything built from your documents belongs to you, runs in the environment you choose, and leaves with you if you leave. Saphenia never trains on your data. For the wider product, see what Saphenia does. Building or buying AI agents sets out the cost of an internal build, and the pricing article explains what drives the cost of a deployment.