ERRNA expert insight
Proof of Reserves Is Not Enough: Go/No-Go Controls for Crypto Platform Boards
Every platform that holds customer crypto eventually gets one question from its board, its auditors, or its customers: can you show, today, that what you owe customers is covered by assets you actually control? Many teams answer with a periodic “proof of reserves” report. Oversight bodies have been blunt about the limits of that answer. The PCAOB’s Office of the Investor Advocate has written that proof of reserve engagements are not audits, and the SEC’s investor education staff has issued an investor bulletin making a similar point.
This article is written for the founder, CEO, or board member who has to decide what “reserve assurance” should mean inside the company. It is not legal advice, and it does not tell you which rules apply to you. It gives you a way to ask better questions, a proposed design for answering them, and a set of mandatory go/no-go controls you can hold your executive team to.
- 🎯 Who it is for: founders, CEOs, and directors of exchanges, custody businesses, and white-label operators.
- 🧭 What you get: a five-question assurance model (a proposed design), realistic failure patterns, engineering invariants to demand, and an all-required control table.
- ⚠️ What it does not do: certify any platform as solvent, compliant, or production-ready.
Key Takeaways
- ✅ A point-in-time proof of reserves report is a snapshot of assets. By the regulators’ own descriptions, it typically does not tell you about liabilities, activity between snapshots, or internal controls.
- ✅ Reserve assurance is an operating discipline: a per-tenant, per-asset liability ledger reconciled against proven-control assets on a defined cadence, with every difference classified.
- ✅ An unknown result means completion could not be confirmed. It is not a success and not a verified failure, and it must block sign-off until resolved.
- ✅ Use mandatory go/no-go controls, not a summed score. If any required control is missing, the answer is “no-go” or “restricted launch.”
- ✅ Identifiers in published proofs can themselves be sensitive data. Name a privacy owner before anything is made public.
- ✅ ISO/IEC 27001 and SOC 2 speak to information security and service controls. Neither, by itself, says anything about whether assets cover liabilities.
Why Proof of Reserves Became a Board-Level Question
Key takeaway: A reserve report answers “what did we hold at one moment?” Boards need to answer “can we cover every customer claim, every day, and who knows when we cannot?”
Proof of reserves emerged as a trust signal: a voluntary way for a platform to show that customer assets are backed. The problem is that the signal is easy to misread. The PCAOB advisory notes that these reports typically verify an asset type at a particular moment, likely do not address the entity’s liabilities or whether assets were borrowed to appear sufficient, and provide no assurance about internal controls or governance. The SEC’s investor alert on crypto asset securities adds that a proof of reserves may not disclose what management did between snapshots, may not show whether customers would “stand in line” behind other creditors, and may not protect against assets being moved shortly after the report.
For a board, that translates into a simple discipline: never accept a single artifact as the answer to a continuous question. The table below is a reading aid, drawn from those public descriptions, for what a typical point-in-time reserve report can and cannot tell you.
| Board question | Typically answered by a point-in-time reserve report? | Why |
|---|---|---|
| Did the entity control certain wallets at a moment in time? | Sometimes | Depends on the procedures agreed. Scope is set by management in many engagements. |
| What does the entity owe customers in total? | Often not | Liabilities are frequently outside the procedures performed. |
| Were assets borrowed or encumbered at the time? | Often not | Encumbrance is not necessarily tested. |
| What happened to assets after the snapshot date? | No | Reports are point-in-time by design. |
| Do internal controls and governance work? | No | Regulators state such reports provide no assurance on this. |
| Does each tenant on a shared platform hold enough? | Only if scoped per tenant | Aggregate totals can hide tenant-level gaps. |
2026 Update: What Has Changed, and What Has Not
Regulatory text keeps moving, so treat this as a dated anchor rather than a forecast. In its September 30, 2025 industry letter, the New York DFS issued updated guidance on custodial structures that replaced its 2023 guidance. It expects custodians to segregate and separately account for customer virtual currency both on-chain and on the internal ledger, and to be prepared to demonstrate reconciliation between books and records and on-chain activity on request. That guidance is addressed to entities supervised by that regulator. The EU’s Markets in Crypto-Assets Regulation also contains safekeeping obligations for providers offering custody. Whether either applies to you is a question for qualified counsel.
The durable lesson sits underneath the changing text: supervisors and courts care whether customer assets are identifiable, separated, and reconcilable. A snapshot does not prove that. A continuously operated reconciliation process can.
How Most Platforms Approach Reserve Assurance, and Why It Breaks
Key takeaway: Most approaches prove one thing well and miss the rest. The gap is rarely technology. It is ownership of the difference between two numbers.
Walk into a typical growth-stage platform and you will find reserve assurance assembled from parts: a finance spreadsheet, a custodian statement, an engineering dashboard, and perhaps an annual third-party attestation. Each part is competent in isolation. The failure sits between them.
| Common approach | What it can show | What it usually misses | Typical owner |
|---|---|---|---|
| Periodic third-party attestation | Control of listed wallets at a date | Liabilities, encumbrance, post-snapshot movement, controls | Finance or CEO office |
| Month-end spreadsheet reconciliation | Historical agreement of two exports | Intra-month drift, in-flight transfers, reproducibility | Finance |
| Custodian statement reliance | What the custodian says it holds | Your internal ledger accuracy; sub-custody terms; per-tenant split | Operations |
| Single omnibus wallet with a dashboard | Aggregate balance now | Per-customer or per-tenant beneficial interest | Engineering |
| Published Merkle proof of liabilities alone | A user’s balance is included in a committed total | Completeness of liabilities and the asset side | Engineering or marketing |
Notice the pattern. Finance owns the ledger, engineering owns the chain, compliance owns the policy, and nobody owns the difference. When the numbers do not match, the first person to see it often has no authority to halt withdrawals and no procedure for classifying what they are looking at.
Operationally this is where unknowns breed. Our related pieces on deposit crediting and reconciliation controls and unknown withdrawal outcomes cover the engineering side for operators. This article stays at the level where the board decides what it will and will not accept.
Why This Fails in the Real World: Common Failure Patterns
Key takeaway: Capable teams fail here because of system and governance gaps: unclear ownership, the wrong reporting grain, and “unknown” silently treated as “fine.” The scenarios below are illustrative composites of patterns, not reports about a specific client.
Pattern 1: The Timeout That Became a Second Payment (illustrative)
A withdrawal request is submitted to a signing or custody service and the call times out. Support sees no confirmation, marks the withdrawal “failed,” and re-credits the customer’s balance. The original transfer was in fact accepted and later confirms on-chain. The customer now holds the funds twice: once at the destination and once on the platform ledger. Each step looked reasonable to the person taking it.
Why intelligent teams still fail: the timeout was treated as a verdict. No durable operation identity tied the request to an approved payload, so nobody could ask the authoritative system, “what happened to this operation?” before acting. For a consequential mutation, an ambiguous timeout is a reason to reconcile authoritative state first, never a reason to blindly retry or re-credit.
Pattern 2: The Cushion Between Tenants (illustrative)
A white-label operator runs several branded exchanges on shared infrastructure and reconciles at the platform level: total customer liabilities versus total wallet balances. One tenant’s surplus quietly covers another tenant’s shortfall, and the aggregate always matches. In an insolvency or a dispute, each tenant’s customers have claims against their operator, not against a pooled cushion.
Why it happens: the report grain was chosen for convenience. Nothing in the reporting pack forced a per-tenant, per-asset view. Our go/no-go controls for white-label exchange go-live go deeper on tenant safety.
Pattern 3: The Clean Snapshot and the Blind Month
An annual attestation passes. Over the next eleven months, treasury moves assets between venues to manage costs, a sub-custodian arrangement changes, and a pending-transfer queue grows. Nobody is wrong, but nobody is watching the relationship between liabilities and assets between snapshots, so a growing gap is first noticed by a customer.
System gap: assurance was purchased as an event, not operated as a control.
Pattern 4: The Proof That Leaked Identities
To signal transparency, a platform publishes proof-of-liabilities data using lightly hashed customer identifiers. Hashes of low-entropy values such as emails or sequential IDs can often be guessed and reversed, so the “proof” becomes a privacy incident. Identifiers can themselves be sensitive data, and publishing them was nobody’s explicit decision.
| Pattern | Governance or system gap | Control that closes it |
|---|---|---|
| Timeout treated as failure | No durable operation identity or authoritative-state check | Run and operation keys bound to payload hash; reconcile before any retry or re-credit |
| Cross-tenant netting | Wrong reporting grain | Per-tenant, per-asset reconciliation; no netting across tenants |
| Snapshot-only assurance | No owner between snapshots | Scheduled runs with aged exception reporting to a committee |
| Identifier leakage | No privacy owner for published artifacts | Named data owner; salted per-user leaves; per-user proof delivery |
A Proposed Framework: The Five-Question Reserve Assurance Model
Key takeaway: Five questions, each with required evidence and a named owner, turn “are we covered?” into something a committee can inspect. This is a proposed design, not an established or certified method.
The model below is a design proposal Errna’s engineers use as a discussion frame for boards. It is not a regulatory standard, an audit methodology, or a product. Adapt it with your counsel, auditors, and risk function.
Customer ledger (liabilities, per tenant, per asset) | v Frozen snapshot at ledger sequence N --> payload hash | v Reconciliation run <-- Control wallets and custodian records | (assets, per tenant, per asset) +--> matched +--> explained in-flight (evidence attached) +--> unknown (blocks sign-off, ages visibly) +--> breach (triggers pre-agreed restrictions) | v Board reporting pack (exceptions, ages, owners)| # | Question | Evidence to require | Failure signal |
|---|---|---|---|
| 1 | Liabilities: What do we owe, per tenant and per asset? | Ledger export reproducible at a given sequence number | Totals that change when re-run for the same cut-off |
| 2 | Control: What do we control, and how is control proven? | Inventory of every wallet and account, with proof of control and custodian confirmation | Wallets nobody can name or sign for |
| 3 | Segregation: Whose assets are they? | Account titling and ledger separation of customer and corporate assets, as your regime requires | Commingled treasury and customer balances |
| 4 | Continuity: What happens between checks? | Scheduled runs, defined cadence, alerts on drift | Assurance that exists only on report dates |
| 5 | Exceptions: What do we do when we do not know? | Classification states, aging, escalation, pre-agreed restrictions | Unknowns closed by assumption |
The Four Classification States
Every difference between liabilities and assets must land in exactly one state. The numbers below are illustrative only, to show the mechanics.
| State | Meaning | Illustrative example (one tenant, one asset) | Board consequence |
|---|---|---|---|
| Matched | Assets in control equal liabilities | Ledger 10,000.00; confirmed control 10,000.00 | Report only |
| Explained in-flight | Difference is covered by evidenced pending items | Ledger 10,000.00; confirmed 9,850.00; 150.00 in a withdrawal with confirmed on-chain status | Report, with age of each item |
| Unknown | Completion could not be confirmed | Ledger 10,000.00; confirmed 9,850.00; 150.00 in a transfer whose status cannot be verified | Blocks sign-off; escalates after the age limit the board sets |
| Breach | Verified shortfall or unexplained gap | Ledger 10,000.00; confirmed 9,700.00; no evidence for the 300.00 gap | Pre-agreed restrictions apply |
One rule matters more than the rest: unknown is not success and it is not verified failure. It means completion could not be confirmed. A platform that rounds unknowns into “matched” to keep a dashboard green has built a system that cannot detect the very event it exists to detect.
For the custody architecture that feeds Question 2, see our institutional guide to digital asset custody and the custody architecture blueprint.
What Your Engineers Must Build: Idempotent, Tenant-Safe, Reconcilable
Key takeaway: You do not need to read code to govern this. You need to ask whether five invariants exist and ask to see the evidence.
Boards sometimes assume reconciliation is a reporting script. For a platform moving customer funds, the run itself and the actions it triggers (halting withdrawals, freezing an asset, re-queuing a transfer) are consequential operations. They need the same discipline as payments. Ask your CTO to demonstrate each invariant below.
- Durable, tenant-scoped operation identity bound to an immutable payload hash. Each reconciliation run is identified by tenant, asset, and ledger cut-off. The approved snapshot manifest is hashed. Reusing the same key with a changed payload is rejected, never silently overwritten.
- Atomic claim. Only one worker may own a run at a time. Claims are made with a single conditional write, not a read followed by a write.
- Verified acknowledgment. An inbound event (a custodian callback, a chain-watcher notification) is acknowledged only after it is durably recorded and any resulting work is scheduled in the same atomic step, or the gap is explicitly recoverable.
- Terminal failure versus unknown. “Failed” requires positive evidence from the authoritative source (for example, the custody provider’s operation record, or finality rules for your network). Absence of a response is not evidence. Anything else stays unknown and keeps aging.
- Privacy ownership. A named owner decides what identifiers appear in any exported or published proof, how salts are generated, and who can see per-user inclusion data.
Also insist on the rule for ambiguous timeouts: before retrying a withdrawal, a freeze, or any consequential mutation, the system queries authoritative operation state and reconciles. It does not blindly retry. A legitimately later operation (the next day’s run, a new withdrawal by the same customer) gets a new identity. A corrected re-run of the same cut-off is a new run that explicitly references the one it supersedes.
The sketch below is illustrative only. It is a PostgreSQL-style outline of the invariants, not a vendor API contract or an Errna product interface, and it needs adaptation to your stack, isolation level, and failure testing.
-- Illustrative sketch. Not a vendor API contract. CREATE TABLE reserve_run ( tenant_id text NOT NULL, asset_code text NOT NULL, run_key text NOT NULL, -- tenant + asset + ledger cut-off payload_hash bytea NOT NULL, -- hash of approved snapshot manifest status text NOT NULL DEFAULT 'pending', claimed_by text, claim_expires_at timestamptz, supersedes_run_key text, PRIMARY KEY (tenant_id, asset_code, run_key) ); -- 1) Register the run and its work item in ONE transaction. BEGIN; INSERT INTO reserve_run (tenant_id, asset_code, run_key, payload_hash) VALUES ($1, $2, $3, $4) ON CONFLICT (tenant_id, asset_code, run_key) DO NOTHING; SELECT payload_hash FROM reserve_run WHERE tenant_id = $1 AND asset_code = $2 AND run_key = $3; -- If the stored hash differs from $4: ROLLBACK and return a conflict. INSERT INTO outbox (tenant_id, topic, run_key, payload_hash) VALUES ($1, 'reserve_run.requested', $3, $4) ON CONFLICT (tenant_id, topic, run_key) DO NOTHING; COMMIT; -- 2) Atomic claim (a lease) by exactly one worker. UPDATE reserve_run SET status = 'claimed', claimed_by = $5, claim_expires_at = now() + interval '10 minutes' WHERE tenant_id = $1 AND asset_code = $2 AND run_key = $3 AND payload_hash = $4 AND (status = 'pending' OR (status = 'claimed' AND claim_expires_at < now())) RETURNING run_key; -- Zero rows: another worker owns it, or it is already terminal. -- 3) Target-side conditional mutation (a real compare-and-swap). UPDATE asset_controls SET withdrawals_enabled = false, version = version + 1 WHERE tenant_id = $1 AND asset_code = $2 AND version = $6; -- Zero rows: state changed under you. Re-read, then decide again.Three cautions on that sketch. First, a read followed by a comparison and a separate write is not compare-and-swap; the conditional logic must live in the target’s own statement or be protected by documented serialization. Second, a lease can expire while a slow worker is still running, so downstream effects need a fencing token or conditional writes. Third, exactly-once delivery across systems is rarely available, so design for at-least-once delivery with idempotent handling, and say so in your runbooks.
| Invariant | Question for your CTO | Evidence to see |
|---|---|---|
| Run identity and hash binding | What happens if the same run key arrives with a different snapshot? | A test that shows rejection and an audit log entry |
| Atomic claim | Can two workers process the same run? | A concurrency test with conflicting claims |
| Verified acknowledgment | Can we acknowledge an event and lose the work? | Crash-recovery test between receipt and scheduling |
| Unknown handling | What state does a timed-out status check produce? | A run that remains unknown and ages on a dashboard |
| Privacy ownership | Who approved what identifiers appear in exports? | A named owner and a documented decision |
For the broader reliability design behind withdrawals and callbacks, read idempotent withdrawals and webhooks.
Risks, Constraints, and Trade-Offs Boards Should Accept Knowingly
Key takeaway: Continuous reconciliation costs money and sometimes causes halts. Those costs are the price of detecting problems early, but they should be chosen, not discovered.
| Trade-off | Upside | Cost or risk | Mitigation to discuss |
|---|---|---|---|
| Fail-closed on unknown | Prevents compounding an unverified gap | False positives can pause withdrawals and frustrate customers | Per-asset restrictions, age limits set by the board, fast classification staffing |
| Per-customer wallets versus omnibus wallets | Clear beneficial interest per customer (per-customer); lower fees and simpler ops (omnibus) | Per-customer adds operational complexity; omnibus needs strong internal records to show each customer’s interest | Choose with counsel; document records and audit trail either way |
| Publishing proofs | Customer-verifiable inclusion | A proof of inclusion does not show that all liabilities were counted; it may expose identifiers | Pair with independent ledger review; salted per-user leaves; privacy owner |
| Third-party attestation | Independent eyes on specific procedures | Scope is often management-defined; not an audit; point in time | Read the scope statement; map it to your five questions |
| Reliance on a custodian or sub-custodian | Specialized controls | Your ledger accuracy and per-tenant split remain your problem; sub-custody terms matter | Contractual titling and segregation terms; independent reconciliation to the custodian’s records |
| Higher reconciliation frequency | Shorter exposure window | Compute, on-call, and staffing cost | Set frequency by asset risk and transfer volume, not a uniform schedule |
Scope Discipline for Standards and Certifications
Boards often hear “we are ISO certified” or “we have a SOC 2 report” as if either settles the reserve question. It does not. ISO/IEC 27001 specifies requirements for an information security management system. A SOC 2 report addresses a service organization’s controls relevant to criteria such as security and availability, within a defined scope and period. Both are useful signals about how an organization manages security. Neither is a statement that customer liabilities are covered by assets. When a vendor, including us, cites a credential, ask for the certificate or report, the scope, and the period, and match them to your use case.
What This Advice Does Not Cover
- It does not tell you whether you are a custodian, how your assets are legally characterized, or what segregation your jurisdiction requires. That is a legal determination.
- It does not apply in the same way to a purely non-custodial product that never holds customer assets.
- It is not an investment view on any asset.
A Lower-Risk Approach: Mandatory Go/No-Go Controls and a Board Reporting Pack
Key takeaway: Replace the comforting score with an all-required checklist. Any “no” means no-go, or a restricted launch with the missing control named and owned.
Weighted scores invite trade-offs: strong marketing in one area “compensating” for a missing control in another. Reserve assurance does not work like that. A missing control is a hole, not a deduction. Treat the table as an all-required gate before launch, before adding a new asset, and before onboarding a new tenant. It is a decision aid, not a certification of production readiness.
| # | Required control | Evidence | If missing |
|---|---|---|---|
| 1 | Per-tenant, per-asset liability ledger with immutable sequence numbers | A reproducible export for any past cut-off | No-go for that asset or tenant |
| 2 | Complete inventory of wallets and accounts holding customer assets, with proof of control | Signed inventory plus custodian confirmations | No-go |
| 3 | Segregation of customer and corporate assets as your regime requires, documented | Account titling, ledger structure, counsel’s written position | No-go until resolved |
| 4 | Run identity bound to an immutable payload hash; changed-payload reuse rejected | Test results and logs | No-go |
| 5 | Atomic claim, and atomic or recoverable scheduling before acknowledgment | Concurrency and crash-recovery tests | No-go |
| 6 | Unknown state defined, aged, and owned; never counted as matched or failed | Dashboard and escalation runbook | No-go |
| 7 | Terminal failure only on positive authoritative evidence | Documented evidence rules per rail | No-go for affected rail |
| 8 | No blind retry of consequential mutations after ambiguous timeouts | Runbook and test showing reconciliation before retry | No-go |
| 9 | Pre-agreed breach response: who may restrict withdrawals, via conditional mutation, drilled | Drill record and authority matrix | No-go |
| 10 | Named privacy owner for any exported or published proof data | Written decision on identifiers and salts | Do not publish |
| 11 | Independent review whose scope the board has read and mapped to the five questions | Scope statement and mapping memo | Do not cite the review externally |
| 12 | Regular exceptions and aging report to the audit or risk committee | Committee minutes | Restricted launch only |
The Board Reporting Pack
A useful pack is short. For each tenant and asset, show the classification state, the age of every unknown item, the owner, and the date it is due. Add the list of runs rejected for payload conflicts, the count of restrictions applied and lifted, and any change in custody or sub-custody arrangements. The thresholds (for example, how long an unknown may stay open) are decisions for your board and counsel, not industry benchmarks.
What to Do Next, Based on Where You Stand
- All twelve controls evidenced: proceed, and schedule a recurring review. Re-run the gate when you add an asset, tenant, custodian, or transfer rail.
- One to three missing: restrict scope (fewer assets, lower limits, one tenant) until each gap has an owner and date.
- Controls 1, 2, 3, or 9 missing: pause expansion. These govern whether you can know and protect what you owe.
If you plan to launch on a ready platform, our overview of white-label crypto exchange options and the crypto custody integration and crypto compliance services pages describe how Errna approaches these engagements. A reserve-assurance design review is something to scope with us for your situation; it is not a pre-packaged product, and it does not replace your counsel, auditors, or regulators.
Can your team show every control in the table, today?
If the honest answer is “mostly,” you have a gap worth closing before customers or supervisors find it.
Talk to Errna engineers about a reserve-assurance design review for your platform.
Contact UsConclusion: Five Decisions for the Next Board Meeting
Reserve assurance is a decision about what your organization will treat as evidence. Use the following actions as guidance for your next committee cycle.
- Reclassify the question. Record in the minutes that “are customer assets covered?” is a continuous control question, not an annual report question.
- Assign the difference. Name one accountable owner for exceptions between the liability ledger and assets in control, with authority to restrict withdrawals under pre-agreed rules.
- Adopt the all-required gate. Run the twelve go/no-go controls before launch and before each new asset, tenant, or custodian. Do not substitute a score.
- Ban silent unknowns. Require that unknown results are reported with age and owner, and never closed by assumption or by a blind retry.
- Ask counsel and auditors to map scope. Have them confirm in writing which segregation expectations apply to you and what any attestation does and does not cover.
About This Article
Errna is a blockchain and digital-asset technology company founded in 2003, with 1,000+ in-house professionals and 3,000+ delivered projects. Errna lists ISO 27001 and CMMI Level 5 among its credentials and states that it holds SOC 2; these relate to Errna’s own organization and delivery processes. They do not make any client platform compliant, and you should request current certificates and report scope during vendor due diligence. This article is general information, not legal, accounting, or investment advice. Reviewed by Errna Expert Team.
Frequently Asked Questions
Is proof of reserves the same as a financial statement audit?
No. The PCAOB’s Office of the Investor Advocate and the SEC’s investor education staff have both stated that proof of reserve engagements are not audits. They are generally point-in-time, scoped by management, and may not address liabilities or internal controls.
- Read the scope statement before relying on any report.
- Ask whether liabilities and encumbrances were tested.
What is the difference between proof of reserves and proof of liabilities?
Proof of reserves attempts to show the assets an entity controls. Proof of liabilities attempts to show what it owes, often with cryptographic commitments so each customer can verify inclusion of their own balance. Neither alone shows solvency. Inclusion proofs do not by themselves prove that every liability was counted, so they need independent review of ledger inputs.
How often should a platform reconcile customer assets?
There is no universal figure. Cadence depends on transfer volume, asset risk, custody structure, and your regulator’s expectations. Many platforms reconcile ledger to on-chain and custodian records on a scheduled basis, with alerts on drift between runs. Set the cadence with counsel and your risk function, and revisit it when volumes or custody arrangements change.
Does ISO 27001 or SOC 2 prove a platform is solvent?
No. ISO/IEC 27001 concerns an information security management system. SOC 2 reports concern a service organization’s controls within a defined scope and period. They can support due diligence on security practices, but neither states that assets cover customer liabilities.
Should a white-label exchange operator reconcile per tenant?
Yes, as a design principle. Aggregate reconciliation can let one tenant’s surplus mask another’s shortfall. Reconcile per tenant and per asset, avoid netting across tenants, and scope idempotency keys and reports by tenant. Your legal advisers should confirm how each tenant’s customer claims are structured.
What should happen when a reconciliation result is unknown?
Treat it as neither success nor failure. The item stays open, ages visibly, and has an owner. Query the authoritative source before taking any action, and do not blindly retry or re-credit.
- Block final sign-off while unknowns remain open.
- Escalate when the board’s age limit passes.
- Mark failure only on positive evidence.
Can we publish cryptographic proofs without exposing customer data?
It is possible to reduce exposure, but identifiers can themselves be sensitive. Avoid publishing raw or lightly hashed identifiers, use per-user salts, deliver individual inclusion proofs only to the relevant customer, and have a named privacy owner approve the design. Confirm obligations with your data-protection counsel.
Who on the board should own reserve assurance?
Typically the audit or risk committee oversees it, while management assigns an accountable executive for the day-to-day control. The key is that the person who sees an exception has defined authority, and that the committee receives aged exception reports on a regular schedule.
Holding customer assets means owning the proof, not just the report.
Errna’s engineers build exchange, custody-integration, and compliance-aware systems for operators who need controls that hold up between audit dates.