Loading...
We believe in radical transparency about what our cryptographic verification covers and what it does not. This document explains the scope and limitations of Kumry's integrity guarantees.
Cryptographic verification provides mathematical guarantees about data integrity -- it proves that data has not been modified since it was recorded. It does not guarantee the accuracy of the original data input. Think of it as a tamper-evident seal: we can prove nothing was changed, but we cannot vouch for the accuracy of the original content.
Each financial entry passes through multiple verification layers before being committed to the immutable ledger.
User or bank feed creates a financial entry
Mathematical proof: debits = credits, balances consistent
SHA-256 links entry to predecessor in immutable chain
Ed25519 signature proves authorship and prevents tampering
Entry added to integrity structure; root hash updated
Action sealed in tamper-evident audit capsule
Periodic integrity certificate published and anchored
Cryptographic guarantees provided by Kumry Finance
Every journal entry is cryptographically linked to its predecessor via SHA-256 integrity verifications. We verify that no entry in the chain has been modified, deleted, or inserted out of sequence since inception.
Specific checks
Each entry is signed with an Ed25519 elliptic-curve key. We verify that every signature was created by a valid signing key and that the signed content has not been altered.
Specific checks
Financial records are organised into integrity structures. We verify that the root hash correctly represents all leaf entries and that inclusion proofs are mathematically valid.
Specific checks
Our mathematically verified accounting engine mathematically proves that double-entry invariants hold at all times. This goes beyond testing -- it provides mathematical certainty.
Specific checks
Audit capsules are cryptographically sealed records of every system action. We verify that capsule seals are intact and that no capsule has been tampered with or removed.
Specific checks
Integrity certificates form a chain that can be independently verified. We validate the full certificate chain from the most recent certificate back to the genesis state.
Specific checks
Limitations of cryptographic verification
We do not verify the accuracy of data from external sources. If a bank feed reports an incorrect transaction amount, our system will faithfully record and chain that incorrect amount. We verify the chain is intact, not that the original data was correct.
Bank feed data is provided by third-party aggregators and financial institutions. We cannot verify that the bank has reported transactions accurately, only that the data we received has not been modified after receipt.
While our AI achieves 98%+ accuracy, categorisation suggestions are exactly that -- suggestions. We do not cryptographically verify that a transaction was categorised correctly, only that the categorisation decision was recorded and has not been altered.
We verify that accounting invariants hold (debits = credits), but we do not verify that a user chose the correct account codes, applied the correct GST treatment, or made sound business decisions.
We cannot verify or guarantee the uptime, accuracy, or security of third-party services you connect (bank feeds, payment processors, etc.), only that our integration layer handles their data securely.
If you import historical data from another system, we verify the chain from the point of import forward. We cannot retroactively verify the accuracy or integrity of data from your previous accounting system.