For risk and compliance teams
Security and trust
What we do to protect member data, who handles it, and where we are on independent assurance, stated plainly. Last updated October 2026.
Where we are
| Built and working | Reviewed | Not yet |
|---|---|---|
| Role-based staff console with two-person approval and an audit trail. Two-factor sign-in for staff and members. Encryption in transit and at rest. A dedicated deployment per client. | Internal security review in several waves, with findings fixed and covered by tests. Automated vulnerability checks on every change. | An independent penetration test and a SOC 2 audit are planned, not done. Backups are not yet copied to a second region. |
No client is live on Coreledgerpay today, and no real money has moved: payment rails in the demo are simulated and vendor integrations run in sandboxes.
Where data lives
- Hosting: Microsoft Azure. The flagship runs in West US 2. A client's own deployment runs in the region the client chooses.
- One deployment per client: each client has its own database, its own cluster resources and its own configuration. No client's data shares infrastructure with another's, by design and permanently.
- Backups: the database keeps point-in-time backups for 35 days; identity documents in storage can be restored for 7 days after deletion. Copies to a second region are not enabled yet.
How data is protected
- In transit: every public endpoint uses HTTPS, with HSTS.
- At rest: databases and storage are encrypted by Azure. The most sensitive identity fields (date of birth, address, ID number) are also encrypted by the application with a separate key held in Azure Key Vault, so a database copy on its own does not expose them. Staff two-factor secrets are encrypted the same way.
- Passwords and secrets: passwords are stored only as salted hashes. Service secrets live in Azure Key Vault, not in code or images.
- Workloads: services run as non-root containers with restricted privileges, and talk to each other with an internal key.
Who can do what
- Staff roles: support, compliance, finance and admin staff each see only what their role needs.
- Two-person approval: a manual balance change must be approved by a different staff member than the one who requested it.
- Audit trail: every staff action is recorded with who, what, to whom and when. If the record cannot be written, the console reports an error rather than success.
- Console protections: two-factor sign-in, lockouts after repeated failures, automatic sign-out when idle, and sensitive values such as account and ID numbers masked until a reviewer asks to see them.
- Members: sign-in from a new device is confirmed by an emailed code; two-factor sign-in with an authenticator app and recovery codes is available; abusive request patterns are rate limited.
Testing and assurance
- Internal reviews: several waves of security review of the money-handling, sign-in and staff code, with real findings fixed and covered by regression tests.
- Automated checks: tests, static analysis and a dependency vulnerability scan run on every change, and a failing scan blocks release.
- Independent assurance: an independent penetration test and SOC 2 are planned. Neither has been done, and we do not claim either.
Who handles data
| Provider | What it does | Data involved |
|---|---|---|
| Microsoft Azure | Hosting, database, file storage, email delivery, and the model behind the assistant | Everything the service stores or processes |
| Persona | Identity verification | ID images, selfie and the details a member submits for verification |
| Sentry | Crash reports | Technical details about an error, such as app version and device type |
| Cal.com | Booking a walkthrough | Your name, email, chosen time and answers on the booking form |
| Cloudflare | DNS and forwarding of mail sent to our own addresses | Website addresses and our inbound mail, not member data |
A client's own deployment also connects to the client's own sponsor bank, card, core and payment providers, which the client contracts with directly.
Shared responsibility
Coreledgerpay is software, not a bank. A client brings its own charter or sponsor-bank relationship, its own KYC and AML programme, and its own card and payment rails, and is responsible for operating them. We are responsible for the application, the deployment and the controls described above.
Reporting a problem, and what we can send you
- Found a vulnerability? Email dev@coreledgerpay.com (also in our security.txt). We will acknowledge it and keep you informed.
- Doing a vendor review? We will complete your security questionnaire and can share the technical architecture and security-posture write-ups from our investor overview. Book a walkthrough or email us.
See also our privacy policy and terms.