Real-World Example
Jane Doe is identified by her last name, date of birth, and last four digits of SSN. Jane opts out of SMS after receiving a communication from ABC Collections.
The system should link that opt-out to Jane’s consumer identity, update the Compliance Dashboard, and flag Jane as SMS restricted. If ABC Collections later schedules a text campaign, Jane should not be treated like a normal SMS recipient.
That restriction should follow Jane’s identity, not only the phone number she used when she opted out. If Jane’s contact details change later, future SMS attempts tied to the same identity should still be blocked.
Visual Flow
Consumer Identity Model
Compliance restrictions should be tied to the consumer identity, also known as the ecoAddress identity model. The matching identity is built from:
- Last name.
- Date of birth.
- Last four digits of SSN.
This identity is used to track SMS opt-outs, email opt-outs, disputes, refusal-to-pay indicators, and other compliance restrictions. Restrictions apply to the person, not only to one phone number or email address.
Included Compliance Records
- Disputes.
- Refusal to pay.
- SMS opt-outs.
- Email opt-outs.
- Expired or inactive accounts.
- Other compliance-related restrictions.
How It Should Work
- It should centralize consumer compliance records for review, export, audit, and internal sync.
- It should highlight disputes, refusal-to-pay indicators, SMS opt-outs, email opt-outs, expired accounts, and other compliance restrictions.
- It should tie opt-outs and restrictions to the consumer identity whenever PII matching is available.
- It should help creditors prevent prohibited outreach before a campaign, reminder, or direct communication is sent.
- It should maintain consumer-level compliance history even when contact details change.
- It should show only records that belong to the creditor’s account access.
- It should make dashboard totals traceable to the records behind each number.
- It should support export or reporting workflows when creditors need compliance records outside the portal.
How It Should Not Work
- It should not send SMS or email messages to consumers who have opted out of that channel.
- It should not rely only on phone-number or email-address tracking when consumer identity is available.
- It should not mix compliance records from other creditors.
- It should not hide records that need compliance review.
- It should not treat expired or inactive accounts as active records.
- It should not show totals that cannot be reconciled to underlying compliance records.
- It should not lose opt-out restrictions when a consumer updates contact details.
Developer Notes
- Matching is based on consumer PII identity: last name, date of birth, and last four digits of SSN.
- Dashboard totals must reconcile to the filtered records that produced them.
- Data must remain scoped to the creditor company and allowed sub-accounts.
- Communication services must check compliance restrictions before sending.
- SMS and email opt-outs must persist across updated contact methods when the consumer identity still matches.
- Export and sync behavior should preserve enough context for auditability and traceability.
- API reference endpoints are grouped under Creditor API > Dashboard > Compliance Dashboard.
routes/creditor/index.php
app/Http/Controllers/Creditor/ComplianceDashboardController.php
app/Services/Creditor/ComplianceDashboardService.php
- Communication compliance services
- Consumer identity and ecoAddress services
Last modified on June 23, 2026