Choose TigerBeetle or Blnk for your ledger: which fits your team
Choose TigerBeetle if your team wants a purpose-built store for double-entry transfers and is prepared to build the product behavior around it. Its data model is two entities, accounts and transfers, and its schema is fixed. Each field has a defined role, and the TigerBeetle docs state that new features can be supported without adding columns, tables or schema migrations. Choose Blnk if you want a ledger service with balances, inflight transactions, reconciliation and identities available from the start, and you are comfortable running a PostgreSQL-backed service alongside its Redis, Typesense and worker components. The decision turns on three questions: how much ledger behavior you need out of the box, how much appetite your engineers have for building services on a fixed schema, and which operating model your team can staff.
The operating model is the most concrete difference. The TigerBeetle docs recommend 6 replicas for any production cluster, ideally across 3 sites with 2 replicas each, with each replica's data file on a separate disk and machine. Electing a new primary needs 4 of 6 replicas, and the cluster stays available while at least 3 of 6 machines and the primary are up. Blnk's quick start, by contrast, runs from a clone of the repository and docker compose up, served on port 5001. Ask your infrastructure team whether they can operate a multi-site, six-node database cluster with defined disk, network and failover procedures, and whether they can run a Compose stack under your production change and backup controls. Neither answer is wrong, but the staffing implications differ sharply.
Which scenarios favor TigerBeetle and which favor Blnk
This table maps common team situations to the platform that fits them better, along with the condition that drives the choice. Read each row against your own volume, team skills and how much ledger behavior you need before the engine is in place. The main takeaway is that TigerBeetle suits teams that will build the product logic around a fixed, high-throughput double-entry core, while Blnk suits teams that need balances, inflight holds and reconciliation as working features sooner.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| High-volume payments core with its own application services | TigerBeetle | Your services already own the business rules, identities and reporting, and you want a narrow ledger that enforces double-entry and handles very high write rates. The fixed two-entity schema (accounts and transfers) is a strength only if your application maps its products onto it. |
| Wallet or lending product that needs balances, inflight holds and reconciliation quickly | Blnk | Blnk ships inflight transactions that are committed or voided, balance snapshots, overdrafts and reconciliation with custom matching rules. Choose it when these features are needed in the first release and your team can accept building on a 0.x project. |
| Product rules that change often and need flexible data fields | Blnk | TigerBeetle's schema is fixed, so new product attributes must live in your application or a companion database. If product metadata changes weekly and must be queried directly, the ledger service with its PostgreSQL base is the simpler starting point. |
| Team with strong database operations skills and a need for tight control | TigerBeetle | Running a six-replica cluster across three sites, with one data file per disk and machine, is operational work your DBAs must own. Confirm that your team can run replication, upgrades and recovery drills before you commit. |
| Team with stronger application than database skills | Blnk | Blnk's Docker Compose setup brings together the server, worker, Redis, PostgreSQL 16, Typesense, Jaeger and Prometheus. Fewer moving parts you must tune by hand suit a team that is stronger at application code. Confirm how these components are upgraded and backed up in your environment. |
| Team that wants a managed option | Blnk | Blnk Cloud deploys a managed Core with a dashboard for managing transactions. Ask whether it fits your data residency and audit requirements, since self-hosting in your own infrastructure may be a condition of your compliance posture. TigerBeetle has no managed option in the supplied facts, so confirm any hosted offering with the vendor. |
| Need for an auditable, append-only history of corrections | TigerBeetle | Recorded transfers cannot be erased, and corrections are posted as separate reversing transfers. This suits teams whose assessors expect that property at the ledger layer. Blnk's reconciliation and inflight features still need to be validated against the same audit expectation. |
How TigerBeetle and Blnk are built and what that means for operations
TigerBeetle is a single purpose transactions store with a fixed schema and a replicated cluster you must size and place carefully. Blnk is a ledger application with several supporting services around PostgreSQL. The cards below cover what each one asks your team to run, monitor and decide before go-live.
Fixed accounts and transfers model
TigerBeetle stores two entities, accounts and transfers, under debit/credit double-entry rules, and its schema does not change as features are added. Recorded transfers cannot be erased, so corrections are reversing transfers. Your team must map products such as wallets, fees and holds onto these fields before build starts, and confirm that the fields you need for reporting can be derived from them without a separate store.
Six-replica production layout
The TigerBeetle docs recommend six replicas for production, ideally across three sites with two replicas each. Each replica's data file should sit on its own disk and machine. Operators must provision three sites, six machines and separate storage, and must verify that the network between sites meets their latency and failover expectations before committing to this layout.
Quorum rules for primary and availability
In a six-replica cluster, electing a new primary needs four of six replicas. The cluster stays available while at least three of six machines and the primary are running. Operations teams should alert on replica loss, rehearse site failure and confirm the exact recovery steps with the vendor, since losing a site plus one more machine can stop writes until the cluster is restored.
Blnk application services
Blnk's Compose file runs a server and a worker alongside Redis, PostgreSQL 16 and Typesense. Each service is a separate failure point with its own configuration, backups and upgrade path. Your team should map which service owns the ledger writes, which holds queued work, and which can be rebuilt from PostgreSQL if lost.
Observability with Jaeger and Prometheus
The Compose file adds Jaeger for traces and Prometheus for metrics. Someone must own dashboards, retention, alert thresholds and log routing, and these tools must be hardened and backed up like the ledger itself if you rely on them for audit evidence. Confirm which metrics Blnk exposes before writing alert rules, since the Compose file alone does not list them.
Core, Enterprise Core and Blnk Cloud
Blnk documents open-source Core, Enterprise Core and Blnk Cloud as separate options. Blnk Cloud runs a managed Core with a dashboard, which shifts patching and hosting to the vendor. Before choosing, ask which features differ between Core and Enterprise Core, where data resides under Blnk Cloud, and who is responsible for backups, restores and incident response in each model.
Capabilities compared: what each gives you and what you still build
This table sets TigerBeetle's transactions database against Blnk's ledger service, row by row, so you can see which ledger functions arrive ready to run and which your team still builds. Read the cells as a split: TigerBeetle supplies the posting engine and strict double-entry core, while Blnk supplies the surrounding ledger workflows on PostgreSQL. Where a row shows application work, confirm the exact scope against each project's current documentation before you plan.
| Capability | TigerBeetle | Blnk |
|---|---|---|
| License | Apache-2.0 | Apache License 2.0, with paid Enterprise Core and Blnk Cloud options |
| Latest supplied release | 0.17.9, released July 6, 2026 (still 0.x) | v0.15.6, released September 28, 2026 (still 0.x) |
| Data model | Two entities: accounts and transfers, with fixed field roles | Ledger service with balances, transactions and identities on PostgreSQL 16 |
| Schema flexibility | Fixed schema; new features are said to need no new columns or migrations | Richer ledger schema; confirm how custom fields and migrations are handled in your version |
| Double-entry enforcement | Built into the core: every debit has an equal and opposite credit | Described as a double-entry ledger; confirm which invariants the server enforces versus the caller |
| Reversal handling for corrections | Recorded transfers cannot be erased; corrections use separate reversing transfers | Application work to define correction flows; confirm the reversal and voiding options in the docs |
| Inflight transactions | Application work to model holds, commits and voids on top of transfers; confirm the pattern you need | Supplied: inflight transactions that are later committed or voided |
| Balance snapshots and historical balances | Application work; confirm what balance history the cluster exposes for your reporting | Supplied: snapshots and historical balances |
| Scheduled and bulk transactions | Application work in the calling services | Supplied: scheduled and bulk transactions |
| Overdrafts | Application work to enforce limits in your posting logic | Supplied: overdraft support |
| Reconciliation with custom matching rules | Application work: external records must be matched in your own pipeline | Supplied: reconciliation of external records against the ledger with custom matching rules |
| Identities and tokenized personal data | Application work; keep personal data in your systems of record | Supplied: identities, tokenized personal data linked to balances and transactions |
| Client libraries | Supplied: .NET, Go, Java, Node.js, Python, Ruby and Rust | Supplied as a self-hosted HTTP service; confirm client SDKs for your stack |
| Observability | Application work to instrument the cluster and calling services; confirm metrics exposed | Supplied: Jaeger and Prometheus in the reference Docker Compose file |
What the Apache-2.0 licenses and Blnk's editions cover
TigerBeetle is licensed under Apache-2.0, so the database software itself carries no per-node or per-transaction license fee from the project. The project describes itself as the financial transactions database designed for mission critical safety and performance. Its current releases use 0.x version numbers, and the most recent one named in the project's release history is 0.17.9, released on July 6, 2026. A 0.x line signals that the project has not yet declared a stable 1.0 interface, so your team should read release notes closely before each upgrade.
- Cost you still carry: Apache-2.0 removes the license line, but you pay for the servers, storage, networking, and the engineers who run a six-replica production cluster.
- Upgrade discipline: Plan a test cluster and a rollback path for every 0.x minor release, since the project has not committed to a stable API.
- Commercial support: The licence does not include vendor support. Ask TigerBeetle or a third party whether a paid support agreement exists and what it covers.
- Clients: Client libraries for .NET, Go, Java, Node.js, Python, Ruby and Rust are documented, and the licence applies to them under the same terms.
- Contractual terms: Confirm with the vendor whether any enterprise features, hosted offerings or support terms sit outside the open-source licence.
Before committing, ask the vendor in writing which features are covered by Apache-2.0 and which, if any, come under separate terms.
Blnk is licensed under the Apache License 2.0, the same permissive licence as TigerBeetle. The project describes itself as an open-source, double-entry ledger for teams building fintech products such as wallets, payments, lending and rewards systems. The latest release named in the project's history is v0.15.6, published on September 28, 2026. Like TigerBeetle, Blnk still uses 0.x version numbers, which means its interfaces may change between minor releases.
- Open-source Core: The Core edition is the self-hosted ledger you can clone and run. The quick start clones the repository and runs
docker compose up, serving the instance on port 5001. - Bundled services: The Docker Compose file starts a server and worker alongside Redis, PostgreSQL 16 and Typesense, with Jaeger and Prometheus for observability. You operate every one of these components.
- Cost you still carry: Hosting, backups, upgrades, security hardening and monitoring of the Core stack fall to your team unless you buy support.
- Licence scope: Confirm that the Apache-2.0 terms cover every feature you plan to use, including identity and tokenization features.
- Fork and modify: Apache-2.0 permits modification, so confirm whether the features you need sit in the open-source Core or in a paid tier.
A practical check is to deploy the Core in a non-production environment and map each feature in your requirements to the edition that provides it.
Blnk's documentation lists Enterprise Core and Blnk Cloud as separate deployment options alongside the open-source Core. Blnk Cloud deploys a managed Core with a dashboard for managing transactions, so the vendor operates the infrastructure on your behalf. The documentation supplied for this comparison does not specify which features Enterprise Core adds, what it costs, or what terms govern it, so those details must come from Blnk directly.
- Managed operation: Blnk Cloud shifts hosting, patching and availability work to the vendor, but your data and transactions sit on infrastructure you do not operate.
- Dashboard: The managed dashboard for transactions is a Cloud feature, so confirm whether the same dashboard is available in self-hosted deployments.
- Feature split: Ask Blnk which capabilities differ between Core, Enterprise Core and Cloud, particularly for reconciliation, identities and overdrafts.
- Pricing model: Request the pricing basis and any usage limits in writing, since no figures are supplied here.
- Data residency: Confirm the hosting region and the data processing terms before placing regulated transactions on Cloud.
Ask for a written feature matrix that names each edition, the licence that governs it and the contract terms that apply.
Blnk offers paid support plans alongside the open-source project. Support is a separate purchase from the licence, so the Apache License 2.0 grants you the code but not a guaranteed response from the maintainers. The supplied materials do not state the tiers, response times, escalation paths or what is excluded, so each of these must be confirmed before you rely on them.
- What you pay for: Support plans are a recurring cost that sits on top of your infrastructure spend and internal staffing.
- What to request: Ask for the response and resolution targets, named severity levels, the coverage hours and the channels available.
- Upgrade assistance: Confirm whether support includes help with 0.x minor releases and migration of schema or configuration between versions.
- Security fixes: Ask how vulnerabilities are disclosed, how patches are delivered and how quickly critical fixes reach supported deployments.
- Exclusions: Check whether support covers your own customizations, integrations with your core systems and the Redis, PostgreSQL and Typesense components.
Request the support plan in writing and attach its service terms to your evaluation file before comparing it with the cost of in-house operation.
What you still build on TigerBeetle that Blnk ships
TigerBeetle gives you two entities, accounts and transfers, and nothing above them. Its schema is fixed: each field has a defined role, and the docs say new features can be supported without adding columns, tables or schema migrations. That is a strength for correctness, but it means the modeling layer sits in your application. You design the chart of accounts, decide how account IDs map to customers, products and internal pools, and set the convention for the code and user_data fields so that a later reader can tell what a transfer was for. Blnk, by contrast, ships balances, inflight transactions, reconciliation and identities as product features on top of PostgreSQL. Before you pick TigerBeetle, list every one of these concepts and mark who will own its definition.
The customer-facing and operational pieces are where most of the work accumulates. Illustratively, a wallet product needs a customer identity model that links several account IDs to one person, a balance view that hides internal suspense and fee accounts, and an external reconciliation pipeline that matches card-processor settlement files against transfers. Blnk documents identities that can be linked to balances and transactions, a tokenization feature for personal data, and reconciliation with custom matching rules. With TigerBeetle you build each of these yourself, and you also build the operator tooling: dashboards, replay scripts for failed matches, and runbooks for corrections, which must be posted as reversing transfers because recorded transfers cannot be erased.
Ask for a written inventory before committing. For each item, confirm whether the TigerBeetle docs, your own service or a third-party tool will own it, who will maintain it, and how changes to account ID or code conventions will be governed across teams. Ask a Blnk deployment team the same questions about its identity and reconciliation features, and check whether their behavior matches your product rules. The effort gap is usually in these components, not in the ledger engine, so estimate them first and treat the fixed schema as a design constraint your team must document.
What drives the running cost of each ledger
The running cost of either ledger is set less by licence fees than by the machines it needs, the people who operate it, and the application code your team writes around it. Both platforms are Apache-2.0 open source, so the quote you request should itemize who is paid for infrastructure, support, upgrades and integration work.
Six-replica TigerBeetle infrastructure
The TigerBeetle docs recommend six replicas for any production cluster, ideally across three sites with two replicas each, and each replica's data file on a separate disk and machine. Ask your infrastructure team to price six machines, separate disks and cross-site network links, and to confirm which site loss the cluster can survive. Those hardware and bandwidth lines recur every month.
Blnk stack infrastructure
The Blnk Docker Compose file runs a server and a worker alongside Redis, PostgreSQL 16 and Typesense, plus Jaeger and Prometheus for observability. Each of these services has its own memory, storage, backup and patching cost, and PostgreSQL carries the ledger data. Ask who sizes, backs up and monitors these components in your environment, and whether the observability tools are kept or replaced by your existing stack.
Engineering skills per platform
TigerBeetle asks your team to operate a consensus cluster and to model money as accounts and transfers in its client library, a skill set few generalist teams hold. Blnk asks for PostgreSQL, Redis and container operations, which most platform teams already run. Estimate the hiring or training cost for the skill you lack, and ask any vendor or partner to name the people who will do the work.
Paid Blnk support and Enterprise Core
Blnk offers paid support plans alongside the open-source project, and its docs separate open-source Core, Enterprise Core and Blnk Cloud. Enterprise Core terms, response commitments and feature entitlements are contract items, not part of the Apache-2.0 licence. Request the written terms, the named features in each tier, and whether support covers your self-hosted deployment. TigerBeetle support terms should be confirmed with its maintainers.
Upgrade effort across 0.x releases
TigerBeetle is at 0.17.9 and Blnk at 0.15.6, and both projects still use 0.x version numbers, which signals that minor releases may change behavior. Plan a recurring upgrade window for each, with staging tests against your own ledger data and a rollback path. Ask each vendor for its documented upgrade and migration notes between minor versions, and who in the quote carries that work.
Application development hours
TigerBeetle provides the ledger engine but not balances views, reconciliation matching, identity links or reporting, so your team writes that layer on top of its client libraries. Blnk supplies inflight transactions, reconciliation rules and identities, so the main build is integration, customization and tests for your products. Ask for an itemized scope of build work for each option, since this is usually the largest variable line in any quote.
Moving a ledger from Blnk to TigerBeetle or the reverse
This sequence moves balances and history from one ledger to the other without losing auditability, and ends with a cutover that both finance and engineering have signed off on. It works in either direction, though the mapping work differs depending on which side is the source.
Freeze the chart of accounts
Finance and the ledger owner agree on the full list of ledger accounts, their currencies, normal balance direction and the rules for which account each transaction type touches, then lock that list under change control. Engineering records the agreed definitions as a versioned document. This step is done when every account in the source system has a named target, and every open question about balance types, such as whether an overdraft is modeled as a separate account, has a written answer. Changes made after the freeze must go through the same review, or the reconciliation later will not tie out.
Map source balances and transactions to targets
Engineering writes a field-by-field mapping. On the TigerBeetle side, each Blnk balance becomes a TigerBeetle account with an ID scheme, ledger and code assigned, and each historical Blnk transaction becomes one or more transfers that preserve the debit and credit pairing. In the reverse direction, TigerBeetle accounts and transfers become Blnk balances and transactions, with the code and user_data fields carried into metadata. Anything that TigerBeetle stores as a fixed field and Blnk stores as free-form metadata needs an explicit rule. The step is complete when a sample of mapped records has been reviewed by both finance and engineering and signed off.
Rebuild identities and reconciliation rules on the target
Identities, personal data tokenization links and reconciliation matching rules do not move as part of the ledger data itself. On Blnk, identities are linked to balances and transactions and reconciliation runs against custom matching rules. TigerBeetle has no identity or matching layer of its own, so the team must rebuild those links in a service or in PostgreSQL that holds the infrequently updated customer data. In the reverse direction, Blnk's identity and reconciliation configuration has to be recreated. Confirm with the vendor and your own environment exactly what Blnk exports, because this determines how much of this step is manual.
Replay or reconcile historical data
Historical records are loaded into the target in their original order, with each source record's identifier kept as a reference so every target entry can be traced back. Because recorded TigerBeetle transfers cannot be erased, a load error cannot be fixed by deleting the transfer. It must be corrected with a separate reversing transfer that references the original, so the plan for corrections is written before the first load. The step is complete when balances in the target match the source for every account at the agreed cut point, and the reversing transfers used during the load are listed in an audit log.
Run both ledgers in parallel
New transactions are written to the source and mirrored to the target for a period agreed in advance by finance, risk and engineering. Each day, a reconciliation job compares balances and inflight amounts between the two systems and reports any difference to a named owner. Differences are investigated, and corrections are posted as reversing transfers or equivalent Blnk entries, never by editing history. The parallel run is considered complete when the mismatch report has been clear for the agreed window and the owners have signed the result. The length of that window is a decision for your organization, not a value this guide sets.
Cut over and retire the source writes
The team sets a cutover point, pauses writes briefly, confirms the final balances match, and then routes all new transactions to the target. The source remains read-only for an agreed retention period so that auditors and finance can query it. Operations confirms that monitoring, alerting and the reconciliation job now point at the new system. The cutover is done when the final reconciliation report shows zero unexplained differences and the change record is approved by finance and the security owner.
Where ledger implementations usually run long
TigerBeetle projects usually run long in the cluster and modeling work, not in the database itself. A production cluster is designed around six replicas, ideally spread across three sites with two replicas each, with each replica's data file on its own disk and machine. That means the network design, site-to-site latency, disk isolation and failure drills must be settled before application code is written. The application side is a client library in the team's language (the docs list .NET, Go, Java, Node.js, Python, Ruby and Rust), and the harder work is mapping the business ledger onto a fixed set of accounts and transfers. Each transfer's ledger, code and user_data fields need agreed meanings, and teams that leave these undefined tend to rebuild them later. Confirm with the vendor and your own infrastructure team how many sites and machines you can actually provide before the timeline is set.
Blnk projects usually run long in reconciliation scope and production hardening. The quick start is a clone and a docker compose up that serves the instance on port 5001, which makes a proof of concept fast. The Compose stack, however, bundles Redis, PostgreSQL 16, Typesense, Jaeger and Prometheus, and each of those needs backup, access control, sizing and patching decisions before production. Reconciliation is the most common source of slippage: external records must be matched to ledger entries through custom rules, and the team has to decide which sources, date windows and tolerance thresholds are in scope before the rules are written. Identity linking and tokenization of personal data add a second design question: which records are identities, who may see them, and how that maps to your data protection obligations. Confirm the rule-engine and identity behavior against the Blnk documentation for the release you intend to run.
Questions teams ask before choosing a ledger
How much effort does it take to run TigerBeetle compared with Blnk?
TigerBeetle asks for less application-side modeling but more infrastructure discipline, while Blnk gives you more ledger behavior to run on a PostgreSQL-backed stack. The TigerBeetle docs recommend 6 replicas for any production cluster, ideally across 3 sites with 2 replicas each, with each replica's data file on a separate disk and machine, so the operating work centers on that cluster topology. Blnk's Docker Compose file runs a Blnk server and worker with Redis, PostgreSQL 16 and Typesense, plus Jaeger and Prometheus, so the work centers on keeping several services, backups and observability healthy. Ask your team to count the components each option adds to your on-call rotation and backup plan, then compare that list against the skills you already have.
Can a small team self-host TigerBeetle or Blnk?
A small team can self-host Blnk more readily because its quick start runs from a repository clone and docker compose up, with the instance served on port 5001. TigerBeetle's production guidance is heavier: 6 replicas, spread across sites and machines, is the documented recommendation, so a small team should plan for that footprint before committing. Either option still needs someone who owns upgrades, backups, monitoring and incident response. If your team cannot staff that role, a managed or implementation-led approach may suit you better, and you should confirm the exact support scope before assuming it.
What does the implementation need from our engineers and finance team?
Engineers need to model accounts, ledgers and transfers in the chosen system, integrate payment or core services through client libraries or APIs, and build the reconciliation flows your processes require. TigerBeetle documents client libraries for .NET, Go, Java, Node.js, Python, Ruby and Rust, and its fixed schema means your team must map each business event onto accounts and transfers with defined field roles. Blnk already provides inflight transactions, balance snapshots, scheduled and bulk transactions, overdrafts and reconciliation with custom matching rules, so engineers spend more time configuring than designing. Finance staff must define the chart of accounts, correction rules, reversal policy and reconciliation tolerances before any build starts.
How long does a migration take, and what sets that duration?
No supplied source gives a migration duration for either platform, so you should ask for a time estimate based on your own written scope. The main drivers are the volume and history of balances you must carry over, how many services read the ledger, how many inflight and reversing flows exist, and how much reconciliation logic must be rebuilt. Moving to TigerBeetle also means restating existing balances as transfers in a double-entry model, while moving to Blnk means reproducing your accounts and transaction states in its data model. Ask for a phased plan with a parallel-run period and a rollback point, and treat any timeline without those elements as incomplete.
Does Blnk Cloud change the decision?
Blnk Cloud can change the decision if you want to avoid running the stack yourself, because Blnk's docs describe it as a managed Core with a dashboard for managing transactions. It does not change the decision if your requirement is to keep ledger data inside your own cloud accounts, data center or air-gapped network, since that requires self-hosting. Ask Blnk what data residency, hosting location, support terms and exit options apply to Blnk Cloud, and whether the Enterprise Core offers features your compliance team needs. Blnk also offers paid support plans alongside the open-source project, which you should price against your internal staffing cost.
How does switching to the other ledger work later?
Switching is easier when you keep a clean boundary between business events and ledger storage, because the ledger becomes a replaceable component. TigerBeetle's recorded transfers cannot be erased and corrections use separate reversing transfers, so historical data can be exported as an auditable trail, but the target system will still need its own mapping of that trail. Blnk's data lives in PostgreSQL, which gives you more standard export options, though the ledger semantics still need to be translated. Plan for a dual-write or parallel-run period, reconcile balances between systems at cutover, and document which system is authoritative for each account type during the transition.
Will DeployOpen recommend one ledger over the other?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so we can help you test both options against your written requirements. We will not give a recommendation before we understand your transaction volumes, reconciliation rules, team skills, hosting constraints and compliance needs. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and we do not publish a price list, so any quote follows from that scope. DeployOpen does not issue audit reports or certifications, so independent assessors remain responsible for those outcomes.
How DeployOpen helps choose, implement or migrate a ledger
DeployOpen helps teams decide whether a purpose-built transactions database or a PostgreSQL-backed ledger service fits their product, then plans, builds and hands over the chosen design inside their own infrastructure. Every engagement starts with a written scope, so the decision, the build and the operating model are agreed before work begins.
How we scope
- Map which balances, transfers and reconciliation flows the ledger must hold, and which stay in your existing databases.
- Document the controls you need for inflight handling, reversals, overdrafts and external record matching before choosing a design.
- Agree the written scope, deliverables and timeline with you before any build work starts, since engagements are fixed-scope.
How we build
- Deploy the chosen option in your cloud accounts, data centers or air-gapped networks, with replica placement agreed up front.
- Build the integration layer, client connections and identity linkage that your payment and product services depend on.
- Test balance integrity, failover behavior and reconciliation accuracy against scenarios your team signs off on.
How we hand over
- Document the schema or data model decisions, the operating runbooks and the backup and restore procedures for your team.
- Prepare the configuration, access and monitoring setup so your operators can run the ledger without outside help.
- Deliver evidence of controls, tests and changes that your compliance and audit teams can review with their own assessors.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer once the ledger is in production.
- Plan version upgrades against the release notes of your chosen platform, with testing before each change reaches production.
- Revisit the design if your product adds lending, rewards or new payment flows that change the ledger's requirements.
