Technical security & data-handling — for partner due diligence.
Security whitepaper · v1 · June 2026

How Settle protects data

A technical overview of Settle's data classification, encryption, tokenization, and no-custody architecture, written for the security and compliance teams of the creditors, debt-resolution firms, and partners we work with.

1. Principles

2. Data classification

Every field maps to a tier that dictates how it may be stored.

TierExamplesStorage rule
Tier 1
never warehoused raw
full SSN/TIN · bank account + routing · card PAN/CVV · gov-ID numbers · biometrics · raw credit report · bank loginVendor token / verdict only. The raw value lives at the provider; Settle keeps a reference + display last-4.
Tier 2
encrypted at rest
SSN last-4 · date of birth · name · address · email · phone · account last-4 · balances · offers · consentsAES-256-GCM field encryption (or masking), access-controlled and audited.
Tier 3
operational
creditor org, matrix rules, references, event logStandard business data.

3. Encryption

In transit: all traffic is TLS; service-to-service calls stay within a private network.

At rest: Tier-2 PII is field-encrypted with AES-256-GCM before it touches the database (e.g. SSN last-4, date of birth), so the values are ciphertext even in backups and replicas. Provider credentials live in an immutable, append-only secrets vault keyed separately from application data — never in plaintext columns.

4. Tokenization

Tier-1 values never enter Settle's database. Instead:

Backing this is an application-layer guard: every inbound request is screened, and any body carrying a raw full SSN, a card PAN, or a bank account/routing number is rejected before it can be persisted — a fail-closed safety net on top of the tokens-first design.

5. Access control & audit

6. No-custody money movement

A settlement is funded into trust at a licensed escrow / banking partner; on acceptance the funds are released directly to the creditor. Settle's funding attestations are cryptographically signed references (Ed25519) — they prove funds are in trust without Settle holding the balance. Settle never debits, holds, or disburses consumer money on its own books.

7. Retention & deletion

Data is retained only as long as needed to operate the service and meet legal/recordkeeping obligations, then deleted or anonymized. Consumers may request access to, or deletion of, their personal data (CCPA/CPRA and similar). Compliance records (consents, authorizations) are retained for their required period.

8. Incident response

We maintain an incident-response process covering detection, containment, and notification. In the event of a data breach affecting personal information, we notify affected individuals and regulators as required by applicable state and federal law, and notify partner organizations per our agreements and DPA.

9. Subprocessors

Settle uses vetted subprocessors for specific functions. The data shared is the minimum each needs; none receive more than their function requires. Current and planned (authoritative list in the DPA):

SubprocessorFunctionData
PlaidBank linking, balance, ACH transfersBank connection (token), balances
Payment processor (Stripe)Subscription billingTokenized card; name, email
Licensed escrow / banking partnerHolds settlement funds in trustSettlement amount, payee
Credit data (Spinwheel / Experian / Equifax)Credit pulls & monitoring (FCRA)Identity to pull under consent
Identity / KYC providerIdentity verificationIdentity inputs; we keep the verdict
Telephony / fax (SignalWire) & SMS gatewayOffer delivery, alerts, OTPPhone/fax number, message
Transactional emailNotifications, verificationEmail address, message
Cloud infrastructure & object storageHosting, encrypted document storageEncrypted application data

10. Compliance posture

Security contact. Questionnaires, DPAs, and vulnerability reports: security@settle.software.

For partner due diligence. The binding terms are in our partner agreement, privacy policy, and data-processing addendum. Last updated June 2026.