What heuristics are used to match Allps presentment responses to loans?
Heuristic matching is a practical, rule‑based method the system uses to link incoming payment responses from the Allps platform to existing loan records stored in Journey.
Because identifiers between systems are not always consistent — for example, loan reference numbers may change, be duplicated, or appear in multiple formats — the application cannot rely solely on exact database joins. Instead, it applies a sequence of intelligent tests and assumptions that allow it to infer which loan a payment most likely belongs to.
2. What is the main matching approach?
The first and simplest step is a direct match: The system compares the loan reference number appearing on the Allps response with known loan numbers already stored in Journey.
If the numbers match exactly after formatting adjustments (such as trimming or removing special characters), the system considers that a definitive match and links the presentment directly to that loan.
3. What happens when an exact match cannot be found?
If an exact match fails, the system does not stop there. It sequentially applies a series of fallback strategies designed to identify a plausible match based on timing, metadata, amount patterns, or text similarity.
These fallback strategies are collectively referred to as heuristics.
4. How does the date‑based heuristic work?
The system checks whether there is a loan with the same reference number that was created before the payment response was received.
This ensures that the link makes chronological sense — a transaction cannot belong to a loan that did not yet exist.
This rule helps filter out recently created loans that might incidentally share a reference number.
5. How does the metadata heuristic work?
Each loan record in Journey contains a metadata field that holds additional and sometimes historical information, such as old reference numbers or external identifiers imported from partner systems.
If the loan reference from Allps is found anywhere inside this metadata field, and the dates of the loan and payment roughly correspond, the system interprets that as evidence of a valid relationship.
This allows the matching process to succeed even when the official loan number was changed or when the payment reference uses a legacy identifier.
6. What happens if the system still cannot identify the correct loan?
When number‑based and metadata‑based searches fail, the application moves on to infer the match indirectly via the client associated with the transaction.
It retrieves the client number from the Allps record (via the promissory details) and looks up that client in Journey. Once the client is identified, it examines all loans issued to that person and applies further heuristic tests within that narrower group.
7. What is the repayment‑pattern heuristic?
For clients with multiple loans, the system compares the installment amount on the Allps response with the repayment amount recorded on each of the client’s loans.
If a loan’s total repayment appears to be a clean multiple of the installment amount — for instance, a loan whose total payment obligation divides evenly by the installment figure — that relationship is considered strong evidence that the presentment belongs to that loan.
This is a numerical heuristic based on the logical structure of loan repayments.
8. What is the text‑similarity (regex) heuristic?
Sometimes loan numbers differ only by formatting or minor variations, such as uppercase versus lowercase letters, extra symbols, or slight rearrangement of characters.
To accommodate such discrepancies, the system performs a textual similarity check. If the reference number from the payment and the recorded loan number look similar — for example, “ML‑1234” and “ML1234” — the system regards them as potential matches.
This is a fuzzy text heuristic, designed to cope with erratic identifier formatting between systems.
9. How does the system ensure accuracy when using heuristics?
Heuristics involve a measure of uncertainty, so the system includes several safety filters and validation conditions to avoid incorrect mappings.
It will only link payments to loans that are in the correct state (for example, loans that have been disbursed but not cancelled), and only if the payment amount and context make logical sense.
If the evidence for a match remains weak after all checks, the record is marked as external, meaning it will be stored but not attached to any specific loan.
This conservative design favors safety and auditability over aggressive linking.
10. What types of heuristics are used overall?
The matching process employs a combination of the following heuristic categories:
Deterministic checks
Exact key matches using normalized reference numbers.
Temporal checks
Ensuring the loan existed before the transaction occurred.
Metadata searches
Finding identifiers buried inside the loan’s metadata field.
Numeric pattern analysis
Comparing installment and repayment amounts to find logical correlations.
Textual similarity tests
Matching reference numbers that differ only in format or case.
Fail‑safe handling
Avoiding data corruption by labeling uncertain matches as “external.”
Together these techniques produce a layered, self‑correcting matching mechanism that gracefully degrades from strict precision to informed approximation.
11. Why is such a multi‑stage approach necessary?
Cross‑system financial integrations rarely maintain perfectly synchronized identifiers. Reference numbers may be reformatted by payment gateways, duplicated by resubmission, or lost during account migration.
Without heuristics, a large portion of legitimate payments would remain unlinked, leading to incomplete financial histories and manual reconciliation work.
The multi‑layered heuristic strategy therefore ensures a high match success rate without compromising data integrity — automating the reconciliation process while preserving verifiable traceability.
12. What happens when heuristics succeed or fail?
When a heuristic successfully identifies a likely loan, the loan’s unique ID and related client and branch data are assigned to the payment record. This then triggers standard processing steps such as webhook notifications, client account updates, and potential collection workflows.
If no heuristic achieves a confident match, the presentment is still logged for audit purposes but marked as external. This prevents it from interfering with financial balances while still preserving it for possible manual review.
In summary
The system does not rely on a single rule to link Allps presentments to Journeys loans. Instead, it uses a progressive, hierarchical set of heuristics — beginning with exact key comparison and moving through date validation, metadata analysis, payment‑pattern reasoning, and text similarity — while maintaining strict safeguards against false matches.
These heuristics collectively allow the platform to reconcile external payment data with internal loan records even under inconsistent or partially missing references, ensuring robust automation with traceable accountability.
Last updated
Was this helpful?