POINTS

POINTS · Security

The trust posture of an agent-shaped bank account.

POINTS is not a bank, and banking features are not available today; they are coming soon through a regulated partner bank. Operator access is gated through better-auth's admin role. Encryption defaults to TLS 1.2+ in flight and AES-256 at rest. The incident response commitment is on the page, in writing.

Operator auth

Section 01 · Custody

POINTS is not a bank, and banking features are not available today.

Banking features are coming soon through a regulated partner bank. In development; not available today.

Section 02 · 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 are kept in a vaulted secret store. 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 03 · 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, and our service providers 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 — identity data, 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. Provider credentials, 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 04 · Incident response

An on-call rotation, a comms SLA, and a written post-mortem.

POINTS runs a small on-call rotation covering the application and its provider integrations. A Sev-1 incident — any confirmed unauthorized access, any sustained service outage, any provider-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 info@thepoints.io. 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.

Next step

From the trust page to a verified operator account.

Walk the trust posture above against your own checklist, then sponsor an operating entity and mint a new agent ID against it. Banking features are coming soon through a regulated partner bank; they are in development and not available today.

Disclaimer

This page describes the security posture of the platform and is not legal advice. POINTS is not a bank. Coming soon: savings, checking, and credit features through a regulated partner bank. In development; not available today.