SSettlaDocs

Reference

Privacy & Security

Settla holds who you are and where money can reach you — data whose over-disclosure directly enables fraud. Privacy is not a feature here; it is the core safety property of the product.

The One Rule

Settla resolves identities, discloses endpoints, and recommends routes. It never moves, holds, custodies, processes, or settles money, and holds no balances. This narrows the funds-handling regulatory surface — but it does not reduce privacy obligations, because the data held is precisely “where to send money, to whom.”

Design tenets

  • Privacy-by-default. New aliases and endpoints default to unlisted; nothing is enumerable without explicit opt-in to public.
  • Minimal disclosure. Resolution returns the least data a requester is entitled to — never more.
  • Consent-based sharing. consent_required endpoints are disclosed only under a valid grant.
  • Fail-closed. Unknown privacy → treated as private; consent state unavailable → omit; scope ambiguity → deny.
  • Auditable & anti-correlation. Every disclosure-relevant action is recorded; the directory resists mapping and enumeration.

Privacy levels

Set per alias and per endpoint, independently. The effective disclosure is the intersection of both.

LevelResolvable bySearchableConsent
publicAnyone with the exact identifierOnly via opt-in directoryNo
unlistedOnly with the exact identifierNeverNo
privateOwner/admin only — never externallyNeverN/A
consent_requiredA consumer with a valid ConsentGrantNeverYes

Note

public ≠ enumerable. Public means “resolvable given the identifier,” not “browsable.” There is no list-all surface at any level; the only discovery path is the opt-in public directory, which returns public aliases only.

Minimal-disclosure engine

The disclosed set is computed as an intersection:

  • endpoints owned by the identity,
  • ∩ allowed by the endpoint's privacy level (never private),
  • ∩ within the consumer's scope,
  • ∩ covered by a valid, unexpired ConsentGrant where required,
  • ∩ endpoint status is active.

Even for entitled endpoints, only the minimal fields are projected:

  • crypto_wallet → full public receive address.
  • bank / exchange / processor / merchant accounts → last4 + token only, never the full number.
  • internal / future endpoints → public_id + type only.

Privacy invariants

These must never be violated:

  1. Default privacy is unlisted; nothing is enumerable or listable.
  2. private endpoints are never in any external disclosure set.
  3. consent_required discloses only under a valid grant; uncertainty → omit.
  4. Returned fields are the minimal entitled set; sensitive values stay tokenized.
  5. Not-found and not-permitted are indistinguishable in shape and timing.
  6. Revocation/expiry of consent takes effect on the next resolution.
  7. Erasure renders PII irrecoverable via crypto-erasure, while the permanent identity UUID and a non-PII tombstone persist.
  8. Every disclosure-relevant and rights action is audited.

Security posture

ControlHow
Key handlingRaw secrets shown once; only a salted SHA-256 hash is stored. Rotate to invalidate.
Endpoint encryptionAddress values are AES-256-GCM encrypted at rest, bound to the endpoint; never logged in plaintext.
Webhook signingHMAC-SHA256 Settla-Signature with a timestamp; verify constant-time and reject replays.
Tamper-evident auditAudit logs are hash-chained; a verify endpoint detects any tampering.
Anti-enumerationNo enumerable IDs, uniform 404s, per-key distinct-alias breadth quota, and honeytokens.
Human auth (dashboard)Scrypt password hashing, TOTP MFA, short-lived session tokens, httpOnly cookies.

Data-subject rights

“Identity is permanent” is reconciled with erasure rights via tombstoning + crypto-erasure: the permanent UUID and a minimal non-PII record persist, but destroying the per-subject key renders the encrypted PII unreadable everywhere at once. Access, portability, rectification, and restriction (set private, revoke consent, suspend resolution) are all supported and audited.

Legal note

Regulatory framing here is for engineering context only and is not legal advice. Qualified counsel must confirm per-jurisdiction obligations before go-live.