Source of Record architecture
Purpose. Describe how systems typically connect for contingent DCA programmes. Your landscape will differ; the accountability pattern should not: CP owns authoritative customer and balance outcomes; DCA executes and reports. Read the narrative first in Source of Record (conceptual).
Typical landscape
- Core banking or loan system: origination and performing loan servicing until write-off or closure path.
- General ledger (GL) and subledgers: financial aggregates, impairment, recoveries cash posting rules.
- CP recoveries or collections platform: operational account record post write-off: placement, recall, trace fields, often dual-state against DCA.
- DCA platform: dialler, workflow, agent workspace; generates activity and DCA-reported state files.
- Integration layer: file transfer, APIs, validation, quarantine for bad rows.
Boundaries: what lives where
| Question | Usually answered by |
|---|---|
| What does the customer owe for operations today? | CP recoveries book (post write-off path), fed by payments and adjustments |
| What did we recognise financially this month? | GL and finance rules |
| What did the DCA attempt and report? | DCA platform feeds into CP for reconciliation |
| What is the legal demand amount? | May require legal case system; must reconcile to CP operational balance |
File flows (summary)
CP sends: placement, payment and balance updates, account deltas, recall. DCA sends: activity, payments collected, remittance, requests and escalations, reported state. Frequency and ownership sit in Requirements and CP / DCA files.
Implementation pitfalls
- Treating the DCA platform as master for balance because it is easier for agents to read.
- Posting recoveries only from DCA remittance without CP allocation rules, causing GL mismatches.
- Missing recoveries book entirely: spreadsheets become the shadow SoR.
Related: Reporting data lineage · Back to pack home