Platform2 min read
Integrating collections with your loan management system
The integration is rarely hard technically. It is hard because two systems disagree about what an account owes, and the disagreement surfaces in front of a borrower.
Every collections platform has to sit next to the system of record. The lender loan management system knows the contractual truth: what is owed, what was paid, what the charges are. The collections platform knows the operational truth: who was contacted, what they said, what they promised. Keeping those two aligned is most of the integration work, and almost none of it is about the API.
Decide what is authoritative, once
The outstanding amount has exactly one owner, and it is the LMS. The disposition, the promise and the contact history have exactly one owner, and it is the collections platform. Ambiguity here is what produces the worst failure in collections: a caller quoting an amount the borrower has already paid. Write the ownership down before writing any code.
The three integration shapes, in increasing order of freshness
- File exchange. A daily file in, a daily file out. Unfashionable, extremely reliable, and correct for most books. The cost is staleness: a payment made at noon is invisible until tomorrow.
- Scheduled API pull. Fresher, more moving parts, and it needs a plan for what happens when the LMS is down during a business window.
- Event-driven. The LMS tells collections when something changes. Freshest, most work, and worth it mainly when same-day payment visibility changes what a caller would say.
Most operations should start with files and move only when a specific pain justifies it. The wrong reason to build events is that it sounds more modern. The right reason is that your callers are quoting stale amounts and it is costing you.
The fields that cause the arguments
- Which amount is being collected: instalment, total arrears, or arrears plus charges. Name the field unambiguously and use one name on both sides.
- The bucket. If both systems compute DPD independently they will eventually disagree, usually around month end.
- Status changes. A closed, settled or written-off account that is still being called is an incident, so status has to travel quickly and be honoured immediately.
- Do-not-contact and consent flags, which usually live in the LMS and must be enforced in collections.
Design for the LMS being unavailable
It will be, during a window that matters. The collections platform should degrade rather than stop: keep working the accounts it already holds, queue what it needs to send back, and make the staleness visible to the caller rather than hiding it. A caller who can see that the balance is as of this morning behaves correctly. A caller who assumes it is live does not.
What to test before go-live
Not the happy path. Test a payment made between two syncs, an account closed while a flow was mid-journey, a borrower whose phone number changed in the LMS, and a file that arrives with a thousand rows missing. Those four are what the first month will actually contain.