Skip to main content

​
Build a neobank over Perflo

Perflo Neobank combines a FastAPI service, a transactional worker, and a React application. Perflo holds and moves the money; the wrapper owns customer identity, confirmation, idempotency, approval tracking, local mandate policy, and operator visibility.

​
Choose fake or live

Use fake for deterministic development and tests. Use live for customer-bound Perflo device sessions against the five reviewed Perflo origins. Production requires live, PostgreSQL, Redis, Vault over Transport Layer Security (TLS), Auth0, authenticated metrics, HTTPS application origins, and disabled debug authentication. Perflo capability requests document residual upstream improvements; they do not gate runtime startup.

Run the quickstart

Start the fake stack and inspect the customer application.

Review production readiness

Check the live canary and operational launch evidence.

Understand the architecture

Follow identity, operations, approvals, and reconciliation.

Deploy one server

Run Caddy, Auth0, PostgreSQL, Redis, and TLS-enabled Vault.

​
Follow operation state

All provider mutations return 202 Accepted with an operation. Browser-approved transfers and mandates expose a trusted Perflo action URL. If a provider write becomes transport-uncertain, the operation enters indeterminate; the worker never resubmits it and uses provider reads for reconciliation.

​
Keep provider data private

The public API never returns provider credentials, beneficiary destinations, token addresses, chains, card credentials, or unmasked bank identifiers. Sensitive provider context remains in Vault ciphertext, and operator operation views omit customer approval URLs.