Designing a Zero-Trust Authorization Layer for Collection Actions

Most recovery technology is built for execution throughput: dialing numbers, streaming SMS, rendering demand letters,
syndicating portfolios, reporting tradelines, or dispatching field agents. The harder architectural problem is distributed across multiple autonomous systems:

Is this specific actor authorized to perform this specific action on this account across this channel right now?

An account eligible during Monday's batch pipeline is not necessarily eligible when the worker thread fires. A payment
clears in the core ledger. Consent is revoked via SMS. A formal dispute is received by outside counsel. A bankruptcy docket
update lands in servicing. When downstream tools act on stale snapshots, the failure is not a lack of rules—it is just-in-time
authorization over fragmented, asynchronous state.

1. Treating Recovery Actions as Zero-Trust Resources Mapping NIST SP 800-207 Zero Trust Architecture directly onto recovery operations separates decision logic from execution logic:

• Policy Information Points (PIP): Creditor ledgers, servicing platforms, payment gateways, dispute queues, court
scrapers, and consent registries supplying timestamped facts.
• Policy Decision Point (PDP): The deterministic adjudication engine that evaluates normalized facts against immutable,
versioned policy packs.
• Policy Enforcement Point (PEP): The dialer daemon, SMS proxy, CRA reporting worker, or case management gateway
that strictly fails closed without a valid permit.
• Policy Administrator (PA): The service managing real-time cryptographic permit issuance, verification, and revocation.
The core operational axiom: No current, valid authorization → No execution.

1. Universal Action Request Contract The request contract remains invariant across communication channels and legal actions. It uses privacy-preserving pseudonymous references (HMACs) rather than raw PII payloads:

{ "request_id": "req_01J9X8K2M1N7", "tenant_id": "issuer_corp_001", "executor": { "organization_id":
"agency_partner_44", "system_id": "dialer_cluster_east", "operator_id": "agent_772" }, "subject_ref":
"subj_hmac_8f9a2...", "account_ref": "acct_hmac_3c1b7...", "action": "CALL", "channel": "VOICE",
"destination_ref": "dest_hmac_9e4d1...", "requested_at": "2026-08-26T15:42:19Z", "context": { "purpose":
"COLLECTION", "jurisdiction": "US-FL" } }

1. Fact Provenance & The Four Epistemic States Incoming evidence cannot be accepted without cryptographic and temporal provenance. Facts carry verification tier, observation timestamps, and explicit TTL windows. The resolver must strictly classify evidence into four states:

• 1. MISSING: A mandatory statutory or policy fact is absent from the graph.
• 2. STALE: The fact exists but exceeds its maximum allowed freshness window.
• 3. CONFLICTING: Two independent authoritative sources contradict each other (e.g., active consent vs. opt-out
• timestamp).
• 4. INVALID: The value violates schema, physical reality, or statutory preconditions.

This creates a vital boundary: BLOCK means the system possesses verifiable evidence that an action is unlawful or
suppressed. NO_USABLE_RESULT means the system cannot guarantee safety and must fail closed. Conflating the two
invites unmeasured fallback risk.

1. Deterministic Decision Engines vs. Probabilistic LLMs LLMs are suited for extracting facts from unstructured legal notices, reconciling dirty records, and preparing human review summaries. LLMs must never make the final authorization decision. The decision function must remain pure and deterministic: f(Normalized Facts, Policy Version, Timestamp) → Decision Packet.

{ "decision_id": "dec_01J9X8K9Z4", "outcome": "BLOCK", "requested_action": "CALL", "reason_codes":
["CONSENT_REVOKED", "OPT_OUT_NEWER_THAN_CAMPAIGN"], "policy": { "pack": "US_CONSUMER_CONTACT", "version":
"2026.08.24", "hash": "sha256:7c9..." }, "facts_hash": "sha256:4f1a2...", "decided_at":
"2026-08-26T15:42:19.012Z", "evidence_ref": "ev_01J9X8K9Z4" }

1. Sender-Constrained Permits & Durable Receipts Conventional bearer JWTs are unsafe for high-consequence operations. An Action Permit must be sender-constrained via cryptographic proof-of-possession (RFC 9449 DPoP), audience-restricted, single-use, and short-lived (e.g., 30-second TTL). The architecture cleanly splits authorization into two artifacts:

• Action Permit: Minimal, ephemeral credential verified by the PEP at runtime.
• Decision Receipt: Append-only immutable record stored with full evidence lineage for audits.

1. Closing the Loop: Execution Receipts
   Authorization without verified execution creates an unobservable gap. The PEP must return an Execution Receipt
   confirming when and how the action occurred, forming a complete cryptographic chain: Request → Decision → Permit →
   Execution → Receipt → Audit Graph.

2. Real-Time Revocation & State Synchronization
   Short TTLs reduce exposure, but critical events (cures, bankruptcy filings, attorney notices) happen asynchronously. The
   architecture requires a sub-second revocation bus. A system advertising 5ms decisions is unsafe if an account recall takes
   15 minutes to reach the dialer.

Conclusion
Regulatory exposure in collections stems from broken state synchronization across distributed systems. Building an
independent zero-trust authorization plane solves this failure mode permanently.

Your systems execute. Quorum CAS-1 decides whether the action is authorized.

References

NIST SP 800-207: Zero Trust Architecture

RFC 9700: OAuth 2.0 Security Best Current Practice

RFC 9449: Demonstrating Proof of Possession (DPoP)

CFPB FDCPA Annual Report 2025