Coreledgerpay for Banks & Credit Unions

Coreledgerpay is a digital-banking platform — mobile app, backend, and staff console — that a bank, credit union, or fintech runs as its own, on its own dedicated infrastructure. This page is for the people evaluating us as a vendor, not for investors: if you're looking for funding materials instead, see the investor overview.

The short version

We are looking for our first Design Partner banks and credit unions. Every client gets a fully isolated, dedicated deployment — never shared or pooled with any other client — and a phased, parallel-run path onto it, so you're never asked to cut over blind on day one. Below is what exists today to back that up, plainly stated.

What the platform does today

A full consumer digital-banking feature set, exercised end-to-end by an automated test suite on every change before it ships: account opening and identity verification, transfers and standing orders, savings pots with goals, spending categorization and budgets, disposable single-use virtual cards, a gambling-purchase block, cashback offers, a credit-score tracking module, family/teen sub-accounts with parental controls, and an in-app AI assistant. All of it runs through a single, auditable ledger — every deposit, transfer, and purchase is traceable end to end.

For your own leadership team, a self-hosted executive BI dashboard (built on Metabase) ships with every deployment — interactive charts on new customers, KYC verification funnel, transaction volume, loan portfolio, account balances, card issuance, cashback activations, and platform billing, ready on day one with no analyst or SQL query needed. It runs inside your own dedicated infrastructure and queries your data through a verified, database-level read-only connection — the same "your data never leaves your own environment" guarantee below extends to your analytics, not just your transaction processing.

Your own finance/admin staff can adjust the two levers that control what the platform pays out to customers — the savings pot's APY and the cashback percentage on any Perks offer — directly from the staff console, with every change recorded to the audit log. No engineering ticket, code change, or redeploy needed to run a promotional cashback bump or respond to a rate-environment shift; a competing legacy core banking vendor typically requires a support request and a multi-day turnaround for the same change.

Built for a bank's own risk posture, not a shared platform

• Dedicated infrastructure, permanently. Coreledgerpay does not operate, and does not plan to ever operate, shared infrastructure across more than one client. Your deployment is your own — its own database, its own encryption keys, its own compute — with no cross-tenant boundary anywhere in the system to fail. Standing up a new dedicated deployment is now a documented, repeatable, scripted process (the same Terraform/Kubernetes configuration the flagship instance runs on, parameterized per client), not bespoke engineering work each time.
• Born in the cloud - you manage none of the infrastructure. Coreledgerpay runs entirely on Azure. You never buy, rack, patch, or retire a single server, and you never operate a data center - not a future promise, the same arrangement the flagship instance already runs on today. That's a different posture than a legacy core-banking system with an on-prem appliance or a private data center to staff and maintain, and it's true even though your deployment is fully dedicated to you (see above) - "dedicated" describes isolation from other clients, not that you're the one operating any of it.
• A structured security audit, not a one-time claim. Before any external users or real funds were introduced, every backend service, the mobile app, and the staff console went through a structured internal security and correctness review. Every finding was fixed, covered by a regression test, and verified live in production. That discipline continues on an ongoing basis: automated dependency and toolchain vulnerability scanning (govulncheck, gosec, and container image scanning) runs on every change and hard-fails the build on any finding; a real backup/restore drill has been executed (not just documented) against production; the most sensitive KYC fields (date of birth, address, ID number) are encrypted at rest with a key held separately from the database itself; and any staff action that moves real money requires a second, different staff member to approve it before it takes effect.
• Documented operational runbooks. Incident response, release procedure, and disaster recovery are all written down and have been exercised for real, not assembled after the fact for a pitch.

Moving your existing customers over

If you already have a customer base on Fiserv, FIS, Jack Henry, or any other core, we've built the practical path to bring them onto Coreledgerpay:

• A bulk CSV import to migrate a batch of customers at once, with every row previewed and validated before anything commits, and a bad row (a duplicate email, a missing field) never blocking the rest of an otherwise-good batch.
• A "claim your account" identity re-verification flow — a migrated customer sets their own credentials and re-verifies their identity themselves; nobody's password or session is silently carried over.
• A staff reconciliation queue so every migrated account is tracked and can be checked off against your source system's records, rather than trusted blindly.
• Support for a phased, parallel-run cutover — migrate customers in cohorts and run both systems side by side for a period, rather than a single all-or-nothing cutover, except where a very small client prefers otherwise.

This does not require a live connector into your specific core system — the file format is deliberately core-agnostic, so it works the same way regardless of which one you're moving off of. Ask us for a copy of the migration spec directly.

The Design Partner Program

Being one of our first clients comes with real, concrete terms, not just early-mover risk:

• Locked-in founding-partner pricing for the life of your initial contract — meaningfully below what a standard contract signed later would cost, and usage-based (a fee per active end-user, not one flat fee regardless of your size), which is a better fit for a smaller institution than an enterprise platform fee that costs a 2,000-member credit union the same as a 200,000-member bank. Pricing is discussed directly, once we're talking about your deployment.
• Direct access to our engineering team and real input into what we build next — your priorities shape the roadmap while the partner cohort is still small.
• A phased, parallel-run migration, not a forced big-bang cutover — see above.
• Hands-on onboarding and support through your pilot period, from the same team that built the platform.

Stated plainly: what's still ahead

• A SOC 2 Type II engagement has not yet started — this is a near-universal procurement requirement for selling software to a regulated bank or credit union, and we expect to begin it alongside our first design partners rather than before.
• We do not build a bespoke connector to a specific core banking system (Fiserv, FIS, Jack Henry) speculatively — that's a multi-quarter undertaking we scope with a specific partner once they need it, not before.
• Real money movement, card issuing, and identity verification are each built behind a pluggable interface in the platform, ready for your bank's own banking-as-a-service provider, card processor, and KYC/AML vendor to be connected — each partner brings and configures their own.

Start a conversation

If you'd like to see the platform, discuss becoming a design partner, or have questions about anything above, email dev@coreledgerpay.com and we'll walk you through it directly.

This page is generated from the same source that powers in-app help, so it always matches the current release.