Requirements: interfaces, data, activities, routes
How to use this page. Walk interfaces first (what moves between CP and DCA), then data groups, then capabilities. Routes below are operational codes inside a workstream. They are not the same as the strategic paths in Recoveries decision (contingent vs internal vs sale).
Data domains (visual)
System and data interfaces (typical)
“Client” means the credit provider (CP), which is usually the system of record for balance and payments.
| Interface | Direction | Typical content |
|---|---|---|
| Placement feed | CP to DCA | IDs, balances, arrears, product, PII, permissions, hardship flags, disclosure evidence (as applicable). |
| CP payment and balance feed | CP to DCA | Payments and adjustments on the CP ledger; updated authoritative balance so the DCA does not collect on a stale amount (often daily or same-day batch). |
| CP account update (delta) | CP to DCA | Ongoing changes after placement: new contact details, flags, hardship or complaint hold, legal hold, deceased or bankruptcy updates. |
| Recall / stop instruction | CP to DCA | Recall with reason; suppression where required; SLA for DCA to stop action. |
| Contact and activity outcomes | DCA to CP | Attempts, channel, disposition, promise-to-pay, QA references. |
| DCA payment and allocation file | DCA to CP | Payments collected by the DCA, allocation to accounts, for CP reconciliation. |
| Funds / remittance (net to client) | DCA to CP | Client share after fees, tax lines, chargebacks. |
| DCA request and escalation feed | DCA to CP | Recall request (RQT), hardship identification or referral request, dispute, settlement or closure requests, escalation to legal; optional new contact intel for CP validation. |
| DCA-reported account state | DCA to CP | Reported balance view, arrangement status, PTP state (reconcile to CP authoritative ledger). |
| Document imaging | Both | Letters, call metadata, consent for electronic contact. |
| Directory / skip | As agreed | Trace within privacy rules. |
| Credit reporting | Highly controlled | Often bank-led; DCA listing only with explicit authority. |
Data fields (minimum logical set)
Customer / borrower
Customer ID, DCA internal ID, name, addresses, phones, email, language, vulnerability flags.
Account / contract
Product, limit, principal, fees, interest, arrears, DPD, charge-off date, last payment, security, currency.
Placement
Batch ID, placement date, strategy code, fee tier, recall eligibility, regulatory segment.
Compliance and consent
Disclosure flags and timestamps, channels, DNC windows, third-party contact rules.
Treatment
Route ID, next action, last contact, contact counts, PTP, hardship status.
Recall and recall request
Recall is a control and state change, not a single column. Minimum logical fields include: Recall_Request_Id, Recall_Request_Type (RQT, extension, strategy proposal), Recall_Request_DateTime, DCA_Reported_Recall_RQT_Reason, Recall_Request_Status (open, accepted, rejected, superseded), Recall_Decision_DateTime, Recall_Decision_By, Recall_Effective_DateTime (when stop work must be live), Recall_Reason_Code (CP taxonomy), Recall_Category (compliance, strategic, data defect), Recall_Balance_CP, Next_Strategy_Proposed, Next_Strategy_Actual, Suppression_Profile (what channels must halt). Mirror vendor acknowledgements: DCA_Recall_Ack_DateTime, DCA_Runtime_Status (active, stopping, stopped). Operational narrative: Recall and reassignment.
Operational capabilities (for RFP and SLA mapping)
This table is not a step-by-step journey on one account. It is a checklist of work types to contract, staff, measure, and report: intake, engagement, conduct controls, and exit.
| Capability | Specify in procurement or design |
|---|---|
| Intake validation | Placement or refresh files: schema, balance sanity, duplicates, deceased or bankrupt flags; quarantine rules. |
| Outbound contact | Attempts within channel and frequency rules; first-contact SLA if defined; log channel, time, disposition. |
| Negotiation | Arrangements and settlements within delegated authority; exception path above limit. |
| Hardship | Identify, document, hold or soften treatment; refer to CP when the bank must decide. |
| Dispute handling | Cease or adjust collection where required; track with CP. |
| Legal escalation | Criteria, evidence pack, law firm handoff if used. |
| Quality assurance | Sample calls and letters; coaching; audit evidence. |
| Complaints | Register, investigate, remediate; monthly pack to CP. |
| Exit and handback | End DCA work or execute CP recall: reason codes, stop work, final feeds. |
| Recall request handling | Ingest RQT and extensions; route to CP decision within SLA; log reject reasons; prevent silent deferral on compliance recalls. |
| Recall execution and stop work | Runtime suppression in dialler and letter queues; acknowledgement back to CP; evidence for “stopped” state. |
| Post-recall routing | Structured handoff to internal queue, R2, legal, sale pipeline, or closure; no “recall to nowhere.” |
Recall sequencing and SLA requirements
Contracts should define sequencing: compliance recalls often need intraday or hour-bound stop work; strategic recalls may batch but still need same-day acknowledgement. Tests must prove that placement cannot re-fire while a compliance hold applies unless policy allows an explicit exception with approval. COF-style enforcement patterns are described in COF for DCA.
Strategic path versus operational routes
Use one language for leadership and another for operators at your peril. Strategic paths (contingent vs internal vs sale) decide whether the debt should sit in an external contingent channel at all. Operational route codes decide how work flows inside a channel once placed. A mislabelled mapping between the two is a frequent source of reporting errors when Layer 3 packs mix “route” columns from the DCA without tying back to CP strategy codes.
Capabilities versus journey
Capabilities are durable functions you buy or build: hardship handling, legal escalation, trace, QA. A journey is what one account experiences over time across recalls and placements. Requirements documents should list capabilities for RFP and SLA mapping, then separately define journey states for R1 / R2 traceability fields.
Interface ownership and sequencing
Every interface row needs a named owner on CP side and DCA side, a cut-off time, and a fallback when files fail. Typical dependency: placement before DCA activity; CP payment feed before dialler scripts that state balance; recall before trusting stop work. Parallel runs during migration should list which file is authoritative if two feeds disagree.
Traceability and control fields
Beyond marketing names, store refer and recall timestamps, refer amount, recall balance, CP recall reason, DCA recall request reason, proposed next strategy, and actual next strategy. These fields are not optional extras for auditors alone; they protect monthly cohort reporting from accidental overlap between R1 and R2.
Arrangement reporting and recall requests
Arrangement status must flow in both directions with the same semantics: if CP breaks an instalment plan, DCA must stop promising the old plan; if DCA negotiates inside authority, CP must receive structured outcomes, not only free text. Recall request (RQT) from DCA is not the same as CP recall execution; both timestamps belong in your data model.
Routes (example taxonomy)
Strategic paths (contingent vs internal vs sale) are on Recoveries decision. Below: operational route codes inside a workstream.
| Route code | Intent |
|---|---|
| EARLY_OUTBOUND | High contact, digital first. |
| STRUCTURED_PLAN | Instalments within authority; PTP tracking. |
| HARDSHIP_HOLD | Reduced contact; referral path. |
| LEGAL_REVIEW | Demand or court pathway. |
| CLOSE_RETURN | Uneconomical, disputed, or policy exit. |
See also Programme lifecycle, Recoveries decision, Source of Record, written-off allocation, and CP / DCA files.