Section 01 · Custody
Funds sit in Unit-issued deposit accounts, never on POINTS' balance sheet.
POINTS is the application front-end for an agent-shaped bank account. We do not hold funds directly. Every balance that an operator sees on the POINTS ledger — checking, savings, escrow, sweep, or treasury — is a deposit held in an account issued by Unit, our Banking-as-a-Service partner, and custodied at a Unit-connected FDIC-insured partner bank. POINTS operates the software layer above those rails; Unit operates the chartered banking infrastructure below them.
That separation is deliberate. Eligible FDIC-member-bank balances are pooled at the program level and segregated per accountholder entity on Unit's books — POINTS has no commingled treasury, no master account that sweeps operator liquidity into our own operating funds, and no path through which a POINTS operator balance can be lent, rehypothecated, or otherwise reused. If POINTS were to cease operations tomorrow, no accountholder balance would be on our balance sheet to unwind; every dollar returns to the partner bank's custody of record.
Section 02 · Regulatory & FDIC
Partner-bank regulatory standing and pass-through FDIC coverage.
The partner bank that custodializes POINTS-issued deposit accounts is a state-chartered, FDIC-insured U.S. depository institution, regulated by its state banking department and the FDIC. Unit operates the program manager relationship and compliance program between POINTS and the partner bank; the partner bank is the bank of record on the signature card and the regulated entity on the floor.
Deposit balances swept through eligible FDIC-member-bank sweep programs receive pass-through FDIC insurance up to the standard maximum insurance limit per depositor, per insured bank, per ownership category. The limit is per accountholder entity, per bank — not per POINTS platform account aggregated across operators. Each operator's eligible deposits are insured on the same basis any retail depositor's would be; the coverage follows the depositor identity at the bank, not the application layer above it.
Certain POINTS products are not deposits and are not FDIC-insured: any digital-asset wallet balance is not a deposit and carries no FDIC coverage; any credit product, secured or unsecured, is a loan obligation, not a deposit; any funds in transit pending settlement are not yet on the bank's balance sheet. The product surfaces make the insured and uninsured boundaries explicit at the point of issuance.
Section 03 · Operator auth
Better-auth-backed admin role on every PII surface.
The POINTS operator account uses better-auth for session-bound identity. Admin privileges are not a hidden role — they are a discrete permission flag on the user model and a discrete gate at every protected route. A standard operator role can manage their own fleet; an admin role additionally unlocks the cross-tenant surfaces that read PII (the internal waitlist review, suspicious-transaction reports, KYC queue escalations). No surface that exposes another user's information can be reached without passing the `requireAdmin()` gate first.
Session hygiene follows the better-auth defaults: password hashing at a current memory-hard KDF, signed session cookies scoped to the application origin, idle timeout and absolute expiry on the operator session, and server-side session invalidation on password change and explicit logout. There is no publicly readable listing of admin users, no public endpoint that returns operator PII, and no path through which a session token can be lifted across operator boundaries. Admin access is logged at the application layer with agent id, acting admin, target resource, and timestamp — every read of cross-tenant data leaves an audit row.
Service-to-service credentials use Unit's vaulted API surface. Tokens are short-lived, scoped to the minimum permissions the calling workload needs, and rotated on schedule. The application logs are written from backend services only; operator credentials never appear in application logs, error reports, or telemetry payloads.
Section 04 · Encryption
TLS in transit, AES-256 at rest, scoped secrets in the vault.
Every byte that crosses the public internet between an operator's browser, the POINTS application, the Unit BaaS surface, and the partner bank travels under TLS 1.2 or higher with modern cipher suites. The application refuses downgrades and applies HSTS at the platform layer so browsers never negotiate a cleartext fallback. Security headers — HSTS, a strict CSP applied via the edge proxy, X-Frame-Options to prevent click-jack embedding, and a curated Permissions-Policy that disables unused device capabilities — are applied at the platform level and inherited by every route, including this one.
At rest, primary application databases and object stores are encrypted via cloud-managed disk encryption with AES-256 in provider-managed KMS. Backups inherit the same key envelope and never leave the provider's region without additional envelope encryption. Database columns that carry the most sensitive identifiers — CIP data forwarded to the partner bank, document scans, OFAC match responses — are application-level encrypted before they touch disk, so storage compromise alone does not yield plaintext PII.
Secrets are not in the repository and not in process environment files. The vendor surface for Unit, the partner bank's core processor, the email and storage proxies, and the session secret are read at boot from the platform-managed secret store and cached in memory only for the lifetime of the process. Plaintext secrets cannot appear in logs because they are never loaded into logging-bound scopes.
Section 05 · Incident response
An on-call rotation, a comms SLA, and a written post-mortem.
POINTS runs a small on-call rotation covering the application, the Unit integration, and the partner-bank dependency. A Sev-1 incident — any confirmed unauthorized access, any sustained service outage that blocks fund movement, any partner-bank-side containment event — pages within minutes. Triage on a confirmed Sev-1 opens a channel inside fifteen minutes and a status note inside one hour. Goal-time-to-mitigation tracks the actual incident, not a calendar promise.
Operators are notified through the in-product dashboard, by direct email to the operator primary, and — for events that affect balances, authorization, or session integrity — by an outbound status page entry that links to an incident id. Communications commitment: a first status update within one hour of confirmed severity, a status update at least every four hours until the incident is contained, and a written post-mortem within seven calendar days of resolution covering timeline, root cause, customer impact, and the changes shipped to prevent recurrence.
Operators and partners who need to reach the security team directly can write to [email protected]. Coordinated-disclosure reports are read on the same channel; we acknowledge within one business day and treat reporter identity as confidential unless the reporter asks otherwise.