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.
Every field maps to a tier that dictates how it may be stored.
| Tier | Examples | Storage rule |
|---|---|---|
| Tier 1 never warehoused raw | full SSN/TIN · bank account + routing · card PAN/CVV · gov-ID numbers · biometrics · raw credit report · bank login | Vendor 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 · consents | AES-256-GCM field encryption (or masking), access-controlled and audited. |
| Tier 3 operational | creditor org, matrix rules, references, event log | Standard business data. |
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.
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.
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.
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.
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.
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):
| Subprocessor | Function | Data |
|---|---|---|
| Plaid | Bank linking, balance, ACH transfers | Bank connection (token), balances |
| Payment processor (Stripe) | Subscription billing | Tokenized card; name, email |
| Licensed escrow / banking partner | Holds settlement funds in trust | Settlement amount, payee |
| Credit data (Spinwheel / Experian / Equifax) | Credit pulls & monitoring (FCRA) | Identity to pull under consent |
| Identity / KYC provider | Identity verification | Identity inputs; we keep the verdict |
| Telephony / fax (SignalWire) & SMS gateway | Offer delivery, alerts, OTP | Phone/fax number, message |
| Transactional email | Notifications, verification | Email address, message |
| Cloud infrastructure & object storage | Hosting, encrypted document storage | Encrypted application data |
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.