Consents & contact points

Contact safety depends on several facts that answer different questions:

No single row replaces the others. A verified phone does not prove consent; a consent does not override a hold; an old eligibility decision does not authorize execution later.

Contact-point lifecycle

A contact point is EMAIL or PHONE; contactType is immutable. Phones carry a phoneType of MOBILE, LANDLINE, VOIP, or UNKNOWN—a provider fact with provenance, not a guess based on number format. Mutations go through POST /v1/customers/{customerId}/contact-points and PUT/DELETE on /v1/customers/{customerId}/contact-points/{contactPointId} (UPDATE_LMS_CUSTOMER_CONTACT); current state is read from the customer aggregate, which masks the stored values.

Texting permission lives on the phone

canReceiveSms is the explicit texting permission for one phone contact point—not a consent record. It defaults to false and every change must carry smsPermissionChangedAt:

curl -X PUT "$BASE/v1/customers/412/contact-points/513" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: maya-sms-stop-1" \
  -d '{
    "canReceiveSms": false,
    "smsPermissionChangedAt": "2027-05-01T10:32:00-07:00"
  }'

{ "resourceId": 513, "changes": { "canReceiveSms": false } }

Changing a phone’s value resets canReceiveSms and verification state unless fresh trusted results arrive in the same change—permission attaches to a number, not to whatever number happens to occupy the slot.

Consent records

Consents come from a closed catalog of four regulated types: ELECTRONIC_COMMUNICATION, AUTODIALED_CALL, ARTIFICIAL_VOICE, and UNUSUAL_TIME. There is no channel or purpose scoping on a consent; the record captures that the permission was granted, when, how, and with what evidence. A grant is immutable; revocation closes it.

curl -X POST "$BASE/v1/customers/412/consents" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: maya-autodial-consent-v1" \
  -d '{
    "consentType": "AUTODIALED_CALL",
    "capturedAt": "2026-08-01T17:05:00Z",
    "captureMethod": "BORROWER_PORTAL",
    "evidenceRef": "evd_CONSENT_41"
  }'

{ "resourceId": 71 }

Requires UPDATE_LMS_CUSTOMER_CONSENT. captureMethod records how the grant was obtained: STAFF_ATTESTED, BORROWER_PORTAL, E_SIGNATURE, RECORDED_CALL, IMPORT, SERVICING_PLANE, or PROVIDER.

GRANTED ── bodyless revoke ──► REVOKED

Revocation takes no request body; the server derives the effective time, and the original grant and its evidence remain immutable in history. A later grant creates a new consent record with new evidence; it does not reopen the old record.

curl -X POST "$BASE/v1/customers/412/consents/71/revoke" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Idempotency-Key: revoke-consent-71"

{ "resourceId": 71 }

Consent evidence references are visible only on the audited sensitive read (GET /v1/customers/{customerId}/sensitive); the aggregate shows the consent’s type, status, capture time, and method.

Payment authorization is separate

An electronic-payment authorization is not interchangeable with a communication consent. One-time payments and autopay enrollments carry their own authorizationRef evidence and terms. The CFPB’s preauthorized electronic transfer rule is a useful primary reference; your counsel-approved policy determines the exact journey and evidence for each rail.

Enforcement

The Lending Core owns contact and consent facts. The Servicing Plane combines them with local time, purpose, debt, contact frequency, representation, bankruptcy, cease, litigation, vulnerability, and jurisdiction immediately before execution. See Consent & contact eligibility.