EDD & case management
The lifecycle the registry depends on: Alert → EDD → Suspect or Cleared, plus feedback, revoke and dispute. Without a disciplined EDD loop the shared registry degrades into noise.
4cases in scope
2awaiting EDD outcome
1breaching SLA
1closed & revoked
Open casesalert → suspect / cleared
| Case | Entity | Trigger | Status | Open | SLA | Next action |
|---|---|---|---|---|---|---|
| CASE-2211 | SR-4103 | Velocity — 14 new beneficiaries | ALERT | 2d | 3d left | Complete EDD → Suspect or Cleared |
| CASE-2209 | SR-4104 | Structuring below threshold | ALERT | 1d | 4d left | Branch verification pending |
| CASE-2204 | SR-4101 | Inbound dispute from another PI | SUSPECT | 6d | OVERDUE | Re-EDD — decide revoke or uphold |
| CASE-2198 | SR-4105 | Customer grievance — wrongly listed | CLEARED | 11d | closed | Revoked, customer informed |
FeedbackPOST /feedback · async
Every screening match must return the action taken. This is what makes the registry's risk scores improve rather than drift.
no feedback posted yet…
Dispute & revokePOST /dispute · /revoke
Dispute contests another institution's report on a genuine customer of ours. Revoke withdraws our own report after re-EDD finds the entity clean.
no disputes raised…
Fair-process note. The dispute path is the customer's only remedy against a wrong entry. Treat its SLA as a compliance obligation, not a support ticket — a wrongly listed customer is frozen out across the whole ecosystem.