Controls framework for DCA and recoveries
Purpose. This chapter names the controls that make a DCA programme survivable under scrutiny: not a list of policy PDFs sitting on a portal, but the rules, checks, mechanisms, reconciliations, and approval boundaries that constrain third-party execution, money movement, and data flow. Controls sit in the business narrative, the operating model, and the technical blueprint. They are related to, but not the same as, governance: governance oversees whether controls are designed well and operating; controls are what execute day to day.
Recall is treated here as a control domain because stopping work, changing state, and suppressing contact are how you prevent harm at scale. The full operational story of recall lives in Recall and reassignment. COF (Control Orchestration Framework) is the engineering path that can make certain controls deterministic; it is not duplicated here. Read the mapping in Controls to COF mapping and the blueprint in COF for DCA.
1. Why controls matter
At a high level, many DCA programmes look simple: send accounts, receive payments, monitor performance. In reality they sit among the highest-risk areas in collections because a third party is interacting with your customers, money is often collected outside your core systems, decisions are influenced externally, and data moves across systems every day.
Without clear controls, predictable harm follows: customers contacted incorrectly, payments misapplied, balances inconsistent, regulatory breaches more likely, and financial reporting unreliable. Controls are what make the operating model safe, auditable, and sustainable. Weak controls do not feel weak on day one. They feel like “we can clean it up in weekly reconciliation,” until a complaint or audit shows that operational truth and credit file truth diverged for months.
2. What we mean by “controls”
Controls are not just policies or governance forums alone. They are the specific rules, checks, and mechanisms that ensure the system behaves as expected: validation, reconciliation, approval limits, state restrictions, and evidence that those things actually ran.
In this model, controls sit across data, process, decisioning, third-party behaviour, and financial reporting. Credit reporting is treated later as a major cross-cutting obligation because default-listed debt adds regulated bureau outcomes to ordinary collections mechanics. Policy alone is not a control unless it is applied through systems and evidence. Training is not a control unless behaviour is observable in QA and data.
3. Control layers in the DCA model
Controls exist at multiple levels. They should not be collapsed into a single “controls” label or one team’s checklist. The subsections below are all required for a coherent model.
3.1 Data controls
Data controls ensure correct balance, correct status, and correct customer information on the paths that drive action. Examples include CP balance versus DCA-reported balance reconciliation, payment matching between DCA and CP, and mandatory fields populated and validated before allocation or refresh feeds are accepted.
3.2 Process controls
Process controls ensure work is followed consistently. Examples: an account cannot be actively allocated to multiple DCAs in a way that creates duplicate pressure without explicit policy; recall must remove or stop work on the vendor side within defined SLAs; accounts in hardship (or other excluded states) cannot be placed with a DCA when policy forbids it.
3.3 Decision controls
Decision controls ensure choices sit within authority and policy. Examples: settlement thresholds and override paths; write-off, forgiveness, or abandon approvals; movement from DCA1 to DCA2 with recorded rationale and trace fields.
3.4 Third-party controls (DCA controls)
These controls ensure the DCA acts inside defined boundaries: contact rules and frequency, delegated authority limits for settlements, mandatory reporting of arrangements and material events, and contractual reporting into Layer 3 packs.
3.5 Financial controls
Financial controls ensure reported financial outcomes are accurate: payment reconciliation, commission or fee calculation per contract, and alignment between operational cash, remittance lines, and GL posting rules.
4. Core control domains (what must exist)
The domains below are the backbone. They overlap on purpose: reconciliation, for example, is where several domains meet.
4.1 Source of Record control
This domain is foundational. The credit provider must remain the Source of Record for the receivable while it remains on the bank’s books. Practically: CP balance is authoritative, DCA balance is reported state that must reconcile in, and the GL is financial truth, not a substitute for operational account truth for customer-facing balance questions.
Failure mode: the DCA becomes the de facto SoR, multiple balances coexist, and customer disputes rise. Deep narrative: Source of Record.
4.2 Allocation control
Before any account is sent to a DCA, eligibility must be validated and exclusions enforced: hardship, complaint, deceased, legal hold, and other bank-defined barred states. Control requirement: one account, one clear owner for outbound collection pressure at a time unless policy explicitly allows parallel paths with suppression. Allocation must be logged with at least date, amount (refer amount), and DCA identity, plus strategy or batch references as your model requires.
4.3 Recall control
Recall is a critical control point. It must stop DCA activity in line with policy and contract, including “immediately” where compliance demands it. Capture at minimum: reason, date (effective recall), and initiating party or system source for audit.
DCA interaction: the DCA may request recall or request extension; the CP must approve or reject and record the decision. A request is not the same as a recall. Full process: Recall and reassignment. File design: CP / DCA files.
Failure mode: the DCA continues to contact after recall, or the customer is contacted by both CP and DCA without coordination. That is a conduct breach risk, not only a data defect.
4.4 Payment control
Payments are among the highest-risk control areas. All payments must be captured on CP and reconciled on a rhythm that matches intensity (often daily for active placements). DCA-collected payments must match CP records and post correctly under allocation rules.
Failure modes: payment received but not applied; DCA reports payment late; customer continues to be chased on a stale balance; fee lines diverge from contract.
4.5 Arrangement control
Arrangements must be visible to CP. The DCA must notify CP for new, updated, and broken arrangements in structured form, because CP must be authoritative on what the bank recognises.
Failure mode: DCA believes an arrangement is active and suppresses harsh treatment locally while CP has broken or never recorded the plan. Result: over-contact and conduct risk.
4.6 Reconciliation control
Reconciliation is where many controls come together. At minimum it must cover: CP versus DCA balance, CP versus DCA status, payment matching, and arrangement status alignment, plus recall confirmation where applicable.
| Frequency | Role |
|---|---|
| Daily | Operational control: clear exceptions, prioritise conduct-sensitive breaks |
| Weekly | Trend monitoring: clusters by segment, vendor batch, or new code release |
| Monthly | Governance and audit: ageing, attestation, materiality |
See Reconciliation and exception management.
4.7 Status control
Status must be consistent and mappable across systems. CP status examples might include: Active, Recall requested, Recalled, Closed (your labels will differ). DCA-reported status examples might include: Active, On hold, Returned, Closed. The control requirement is explicit mapping: aligned semantics, documented differences during latency, and reconciliation when CP and DCA disagree.
4.8 Decision traceability control
You must be able to explain why an account moved, who decided, and what data supported it. Minimum control fields include: recall reason, DCA request reason (where relevant), proposed strategy, actual strategy, and timestamps for request versus decision versus execution.
Failure mode: movement happens without an audit trail; vendor rotation looks arbitrary. Trace model: R1 / R2 traceability.
4.9 End-state control
Final states must be controlled: paid, settled, sold, abandoned, forgiven, waiver, or crystallised shortfall into another path. Each must be explicitly recorded, approved where policy requires, and aligned to closure and reporting rules. Silent closure in a vendor tool is not an end state. Definitions: End states and closure decisions.
5. Control ownership
Controls are not owned by one team. A typical split:
| Area | Owner (typical) |
|---|---|
| Data and reconciliation | Operations with finance support on material breaks |
| DCA behaviour and contractual adherence | Vendor management with collections operations |
| Policy and conduct | Risk and compliance |
| Decisioning within delegated authority | Collections / recoveries / credit as per policy |
| Financial reporting and GL integrity | Finance |
“Own” means accountable for design, run-state evidence, and escalation when thresholds breach, not “only team mentioned in email.”
6. Control monitoring (how you know it is working)
Controls must be measurable. Examples of indicators include: reconciliation break counts and ageing, recall SLA breaches, over-contact or duplicate-contact incidents, payment mismatches, arrangement mismatches, and bureau correction backlogs.
These signals should feed monthly reporting, governance forums, and issue tracking with severity, not only informal email. If a control never produces a metric or an exception log, assume it is not really operating.
7. Common control failures
- No clear SoR. Multiple balances exist; nobody can prove placement or recall state from CP systems.
- Weak recall process. DCA activity continues after stop instruction; dialler and letters are not aligned to effective recall time.
- Poor reconciliation. Small errors accumulate until finance, conduct, and audit all find different numbers.
- Missing decision traceability. Movements between DCA1 and DCA2 or to sale cannot be explained with data.
- Over-reliance on DCA reporting. No independent CP validation of balances, cash, or cohort membership for Layer 3.
8. Credit reporting controls (default listed debt)
8.1 Why this matters
A large portion of DCA-managed debt is default listed on the customer’s credit file. That adds an obligation beyond “collect cash”: you are maintaining regulated credit reporting data. If it is wrong, customer harm occurs, complaints escalate, regulatory risk rises, and data correction becomes slow and costly.
8.2 Core principle
The credit provider is always responsible for credit reporting accuracy for its products, even when a DCA is managing the customer relationship day to day. Vendor execution does not transfer that accountability.
8.3 What must be controlled
At minimum, the following must be accurate and aligned to CP operational truth where your regime requires: default status, default amount, default date, payment status, and closure or settlement status. Exact bureau field names vary by market: fix them in policy with legal and compliance.
8.4 Default lifecycle (simplified)
- Default listed. Customer meets default criteria; default is recorded with the credit bureau per rules.
- Debt managed (internal or DCA). Collections continue; payments reduce balance; arrangements may apply.
- Outcome. Debt is paid in full, settled for less, abandoned, forgiven, or sold (among other paths your policy recognises).
- Credit file update. Status must reflect outcome. Often: paid when fully repaid per policy; settled (not paid in full) for partial settlement, abandon, or forgiveness, subject to bank policy and reporting standards.
8.5 Critical control areas
8.5.1 Balance accuracy control
The balance used for credit reporting must match the CP operational SoR (collections or recoveries system of record). Failure mode: credit file shows incorrect balance; disputes escalate.
8.5.2 Payment update control
When a payment is received, CP must update internal balance and update credit reporting status where required by policy and timing rules. Risk: payment received but not reflected on file; customer still appears in default incorrectly.
8.5.3 Status update control (critical)
When the account reaches an end state, status must be updated appropriately. Illustrative mapping (confirm for your bank):
| Outcome | Credit reporting status (illustrative) |
|---|---|
| Paid in full | Paid (or equivalent) |
| Partial settlement | Settled (not paid in full) |
| Abandon | Often settled or equivalent, not “paid in full” |
| Forgiveness | Often settled or equivalent per policy |
This must follow bank policy and credit reporting standards in your jurisdiction.
8.5.4 Timing control
Updates must occur within defined timeframes driven by policy and regulation. Failure mode: delay leaves the customer’s file incorrect after they have paid or settled.
8.5.5 DCA interaction control
The DCA may collect payments and agree arrangements, but in most models must not update the credit bureau directly. Control requirement: credit reporting updates are performed by CP (or strictly governed CP processes); the DCA must notify CP of payments, settlements, arrangements, and disputes that drive updates.
8.5.6 Arrangement and hardship control
If the customer enters hardship or has an active arrangement, credit reporting must reflect the correct status and treatment per policy. Failure mode: hardship is mishandled and reporting remains incorrectly negative.
8.5.7 Reconciliation with credit reporting
Credit reporting data must reconcile with CP SoR balance, payment records, and account status. A practical control check: credit bureau narrative aligns to CP operational truth for the same snapshot rules.
8.6 Integration with the DCA model
The DCA must inform CP of events that drive bureau outcomes: payments, arrangements, settlement discussions, and disputes. Those events drive credit reporting updates and customer impact. Weak handoffs here are a leading cause of “we collected correctly but the file was wrong.”
8.7 Common failure patterns
- DCA agrees a settlement; CP is not updated; credit file stays wrong.
- Payment received; bureau not updated in time; customer complains.
- Account abandoned but default still appears active.
- Multiple balances across systems; bureau reflects the wrong one.
8.8 Governance and reporting
Credit reporting must be visible in monthly reporting (for example default status changes, settlements versus paid in full) and in issue tracking (incorrect listings, delayed updates). It is not a side topic only for the bureau team if recoveries drives the data.
8.9 Final control principle for credit reporting
Credit reporting is not a separate hobby process. It is a direct output of the recoveries and DCA operating model when debt is default listed. If you do not control credit reporting alongside DCA execution, you may still move cash and still fail customers and regulators on fairness and accuracy.
9. Controls and COF engineering maturity
Some controls remain manual at low volume. As obligation density rises, COF can make key rules engineered: state activation, prohibition gates, clocks, arbitration when protections overlap, and decision traces. See COF for DCA and Controls to COF mapping. COF does not replace the control domains above; it changes how reliably they execute.
10. Final design principle
Controls must be designed into the operating model, not added after the fact. If your answer to “how do we know recall stopped work?” is “the vendor promised,” you do not yet have a control.
A DCA model without strong controls will drift operationally, create customer harm, and struggle under audit and regulatory scrutiny. A well-controlled model is traceable, explainable, and consistent, and it supports both performance and conduct.
Related: Governance · Reporting · Source of Record · Back to pack home