1. Overview
Personal finance application that keeps its data in a local database file.
Category: Tasks & Finance.
2. Version and scope assessed
Version assessed: Source commit a4aa421415143406e2557b334137ca1b90b58218.
3. Overall determination
Computing determination
4. Principle profile
| Order | Principle | Finding |
|---|---|---|
| I | Sovereignty | Not assessed |
| II | Longevity | Not assessed |
| III | Locality | ✓ Meets |
| IV | Transparency and Control | Not assessed |
5. Fundamental requirements
| Requirement | Status |
|---|---|
| E1 Independent access to essential information | ✓ Pass |
| E2 Practicable exit and migration | ? Not Verified |
| E3 Independent interpretation and recovery | ? Not Verified |
| E4 Continuing authority and custody over already-created work | ✓ Pass |
| E5 Governability of consequential actions | ? Not Verified |
6. Evidence and verification
- E1: The published, generated SQL schema successfully instantiated in an in-memory SQLite database, yielding 67 schema objects and integrity_check=ok. Account, transaction and related table definitions are available independently. This is an empty schema reconstruction, not an opened .mmb with financial records, attachment files or validated balances. (source), confidence high
- E2: The database can be exported and opened from backups, but migration to another finance application and preservation of every report and rule were not tested. (source), confidence medium
- E3: The unencrypted database can be accessed with SQLite tools, while encrypted databases have limited external access; complete independent recovery was not demonstrated. (source), confidence medium
- E4: The application stores data locally and offers backup copies in the database folder. (source), confidence medium
- E5: The database-open path tries the newer SQLCipher configuration and falls back to the older AES-128 cipher. On the legacy path it offers a warning that rekeying prevents older MMEX versions opening the database, and only rekeys after a Yes response; page-size migration may occur first. This resolves the implemented upgrade warning/control, not actual decryption, cancellation or cross-version recovery. (source), confidence medium
- sovereignty: A positive Sovereignty finding requires established E1, E2 and E4 in the declared scope. The existing access/exit/custody record for Money Manager Ex does not establish all three minimums. The prior positive finding is withdrawn; recorded storage and portability strengths remain facts, not a verified failure. (source), confidence medium
- longevity: E3 is not established for Money Manager Ex's existing essential-record scope. The previous Longevity finding is replaced by Not assessed, not a verified failure or a positive placeholder. (source), confidence medium
- locality: The core budgeting workflow runs from local database files without a provider. (source), confidence medium
- transparency: The positive control observations above do not yet establish whole-scope E5. The methodology requires that minimum before a positive Transparency and Control finding; the previous positive finding is therefore withdrawn to Not assessed, not changed to Does not meet. (source), confidence medium
- E3: The independently instantiated SQL schema is empty. It does not reconstruct financial records, transfers/splits, attachments or encryption state from a real MMB/EMB backup. Readable schema and available cipher code are positive prerequisites, not recovered accounting meaning. (source), confidence medium
- E5: The legacy cipher path offers an incompatibility/rekey warning and requires acceptance, but page-size changes may precede it. Effective cancellation, decryption/migration outcomes and ordinary import/delete/backup correction are not established by that one source control. (source), confidence medium
7. Migration and recovery
Native storage format: SQLite database file (.mmb), with an encrypted option.
Synchronization or runtime model: Local file; sync left to external tools.
Example export or inspection command (not verified against any particular version or data set): sqlite3 data.mmb ".tables"
8. Architectural strengths
Established strengths and their scope are recorded in the evidence and assessment findings on this page.
9. Architectural limitations
- Creating a schema is not recovery of a populated MMEX database.
- Rekeying can change compatibility; the inspected prompt is not an executed decryption/recovery test.
10. Assessment findings and remaining work
Evidence update: 23 October 2026
- Resolved: The published, generated SQL schema successfully instantiated in an in-memory SQLite database, yielding 67 schema objects and integrity_check=ok. Account, transaction and related table definitions are available independently. This is an empty schema reconstruction, not an opened .mmb with financial records, attachment files or validated balances. Source.
- Resolved: The database-open path tries the newer SQLCipher configuration and falls back to the older AES-128 cipher. On the legacy path it offers a warning that rekeying prevents older MMEX versions opening the database, and only rekeys after a Yes response; page-size migration may occur first. This resolves the implemented upgrade warning/control, not actual decryption, cancellation or cross-version recovery. Source.
- Open: A populated .mmb/.emb independently inspected, full transaction/transfer/split/attachment export/import comparison, real encryption migration, deleted-record retention and backups. E5 needs actual cipher/cancellation boundaries and import/delete/backup authority and correction records.
Assessment follow-up: These bounded findings are incorporated into the evidence above. Eligibility and principle ratings are deliberately unchanged; their reconciliation and any blank-status fixes are deferred to the next pass. Reproduction details and retained inputs are in evidence/third-pass/batch-7/.
Human-readable criteria: Can a user export complete records, preserve invariants and metadata, restore them independently, and continue the essential workflow without provider permission?
Rating reconciliation: 24 October 2026
E3 and E5 remain Not Verified for the existing declared scope. Longevity and Transparency and Control are Not assessed pending their required minimums. Sovereignty is also Not assessed because the required access/exit/custody minimums are not all established. This is a targeted evidence decision, not a finding that the product fails. Existing E1, E4 and Locality findings were not re-certified.
Remaining: A populated .mmb/.emb independently inspected, full transaction/transfer/split/attachment export/import comparison, real encryption migration, deleted-record retention and backups. E5 needs actual cipher/cancellation boundaries and import/delete/backup authority and correction records.
Next without installing locally: Acquire a populated synthetic MMB and encrypted test EMB with non-secret credentials, attachments and expected balances/relationships; inspect records and use version-matched migration/cancellation/deletion evidence.
The individual decision and provenance are retained in evidence/rating-reconciliation/batch-8/. Overall: Insufficient evidence.
Contribute verification evidence for Money Manager Ex
Have you tested clean-machine restoration, format migration, or failure rollback for Money Manager Ex? We welcome reproducible laboratory logs, synthetic test fixtures, and independent assessments to resolve open findings.
Read the evaluation protocol · Submit verification records on GitHub
Individually reconciled in rating batch 8 on 24 October 2026. E3/E5 remain Not Verified for explicit missing coverage; dependent unsupported findings corrected. Previously resolved questions are retained, not counted again. E1/E4/Locality were not re-certified by this targeted review. The assessment procedure is described in the methodology.