Skip to main content
CaliberCaliber
See how it works

Security that stays out of your way.

Your data is isolated. Your payouts require approval. Your bank details stay with Stripe. You stay in control.

This page describes the security design Caliber is being built to. It is not a certification or the result of an external audit.

Access is deliberate

Multi-factor authentication is required before anyone enters an organization workspace, the contractor portal, or administration.

Approving a pay run, initiating a payout, and transferring ownership each ask you to verify again, so a signed-in session alone can’t move money.

Design: Supabase Auth with MFA required before protected layouts load any data, and step-up verification (a higher assurance level) for sensitive actions. Sessions are held in secure server-side cookies.

Nothing happens without approval

Initiating a payout requires an explicit payout permission and a second verification step. Money movement stays separate from preparing a pay run.

Staff prepare and review pay runs with the permissions you grant. An authorized approver signs off. Organizations can require that a different person approves than the one who prepared the run.

Design: Four roles — Owner, Admin, Staff, and Read-only Auditor — with action-based permissions scoped to the whole organization or to specific divisions and teams. Optional four-eyes approval.

Data stays isolated

Every organization’s data is separated at the database. Your contractor list, pay runs, statements, and totals are visible only to people your organization has granted access.

Access is denied by default and granted by policy, not by what a screen happens to show.

Design: PostgreSQL row-level security enabled and forced on every table, deny by default, with positive and negative authorization tests for every material action. Server checks are defence in depth, never the only control.

Sensitive data stays with the provider

Bank account numbers never touch Caliber’s database. Contractors enter identity and bank details in Stripe’s own onboarding.

Caliber keeps only Stripe account identifiers and payout status. Raw Social Security and tax identification numbers are never stored in Caliber’s database.

Design: Stripe-hosted onboarding for one connected account per contractor. Caliber stores provider references and readiness status only. Payout webhooks are signature-verified and processed idempotently.

Everything is traceable

Every financial and privileged action — creating, approving, or amending a pay run, and every payout instruction — records who acted, when, and what changed.

Approved records are never edited in place. A correction is a linked amendment, and the original stays visible.

Design: Append-only audit events in a hash-linked chain. Final retention periods are pending legal review; until then, financial records and audit evidence are retained.

Data is encrypted by design

Data is designed to be encrypted in transit and at rest, using the encryption Caliber’s infrastructure providers manage.

Statement files are designed to be stored privately and append-only: a new version never replaces an old file.

Design: Encrypted transport for every connection and provider-managed encryption at rest. Statement storage is private and never overwritten at the same path.

We design for financial-record correctness.

Financial systems require precision. Caliber’s architecture puts correctness, auditability, and data integrity first. Security protects your data without blocking your work.

When you’ll be asked to verify

Identity verification happens before protected data loads, and again before anything that moves money or changes who is in control.

  • Signing in to an organization workspace, the contractor portal, or administration
  • Approving a pay run
  • Initiating or cancelling a payout
  • Transferring organization ownership
  • Sensitive administration actions