Data Handling and Security Policy — Bank Reconciliation Engine

Applies to: The Bank Reconciliation Engine software product (the “Software”), published by Fahmy Project Solutions LLC. This policy does not cover fahmyprojectsolutions.com or any other Fahmy Project Solutions product; see the separate Privacy Policy for the website.

1. Purpose

This document describes how the Software handles data, so that a user or evaluator can understand and verify the claim that data processed by the Software never leaves the machine it runs on.

2. Architecture Overview

The Software is a self-contained desktop application for Windows, packaged with PyInstaller and distributed as a single executable file. When launched, it starts a local web server, built on Flask and Waitress, bound to the local machine only, and opens a browser window pointed at that local server. All processing occurs on the user’s own machine. The Software contains no cloud component, no remote database, and no server operated by Fahmy Project Solutions that the Software communicates with.

3. What Data the Software Processes

A user provides two files: a CSV export of bank credits and a CSV export of open invoices. The Software reads these files, matches transactions according to its internal logic, and produces a reconciliation report displayed in the local browser window. No data other than what the user explicitly provides as input is processed.

4. Network Activity

The Software makes no outbound network calls, and performs no update check or any other network request on startup or during use. It does not transmit input files, matching results, telemetry, usage analytics, or crash reports to Fahmy Project Solutions or any third party.

This claim has been verified directly against the codebase rather than assumed. The Software contains no HTTP client of any kind, such as requests, urllib, or httpx, no email or file-transfer client such as smtplib or ftplib, and no telemetry, analytics, or crash-reporting library. The only network-related code in the Software is: the local web server itself, which binds exclusively to the loopback address 127.0.0.1 and is therefore reachable only from the same machine; a single use of the operating system’s networking library solely to locate a free local port, which never initiates an outbound connection; and the command that opens the user’s default browser, which points to that same local address rather than the internet.

A user can independently verify this by disconnecting the machine from the network before running the Software, or by monitoring outbound connections in Windows Task Manager’s Resource Monitor, or an equivalent network monitoring tool, while the Software runs. The reconciliation report should generate normally with no active network connection.

5. Local Storage and Retention

Input files. When a user submits the two CSV files for analysis, the Software creates a temporary working directory in the operating system’s standard temp folder and saves the uploaded files there. This is a copy written to disk, not an in-memory-only operation.

The reconciliation report. The report itself is not written to disk by the Software. It is generated in memory and returned directly to the user’s browser as the page content. The only way a copy is saved to disk is if the user manually saves the page from their browser; the Software does not do this on its own.

Automatic deletion. The temporary input files are deleted, not left behind, in the ordinary case. When a reconciliation run finishes, whether it succeeds or fails, the temporary directory is removed. The same immediate deletion occurs on early error paths, such as missing, unreadable, or empty input files. As a further safeguard, the Software also sweeps and removes any remaining session temp directories when the process exits normally.

Caveat — interrupted sessions. If a user uploads files, reaches the column-mapping step, and then closes the application or quits without running the reconciliation, the temporary input files are not deleted immediately. They persist until the process exits, at which point the exit-time cleanup removes them. If the process ends abnormally instead — for example, forced closure through Task Manager, a crash, or a power loss — that exit-time cleanup does not run, and the temporary files remain in the operating system’s temp folder until removed by the user or by normal operating system housekeeping.

Logging. The Software writes no operational or transaction log to disk during normal operation. No log file is configured, and console output that does appear, such as the startup address or a notice that the Software fell back to a different port, is printed to the console window only and is never saved to a file. The underlying web server’s own logging is deliberately suppressed to errors only, to keep incidental noise out of the console.

The one exception — startup failure. If the Software fails to start, it writes a diagnostic file named error_log.txt, saved either next to the executable or, if that location cannot be written to, in the operating system’s temp folder. This file contains only operational and diagnostic information: application and Python version, platform details, the executable’s path, a check of whether key modules loaded correctly, and the Python error traceback. It is generated before any CSV file is read, so no transaction data, such as amounts, payer or customer names, or invoice numbers, is ever in scope to be written to it. This file is deliberately not deleted automatically, so a user can send it to Fahmy Project Solutions if they need help diagnosing a startup problem.

Caveat — error_log.txt is overwritten, not appended, on each startup failure. At any given time it reflects only the most recent failure, not a history of past ones.

EULA acceptance record. The Software writes one additional file, eula_acceptance.json, the first time a user accepts the End User License Agreement, in order to avoid re-prompting on every launch. It is saved beside the executable when that location is writable, or in the operating system’s temp folder otherwise; on startup, the Software checks both locations for an existing record. The file contains only the accepted agreement’s version identifier and the timestamp of acceptance. It contains no financial or transaction data. A missing, unreadable, corrupted, or outdated record is always treated as not accepted, and the Software will show the license agreement again rather than assume consent.

6. Third-Party Components

The Software is built on open-source components, including Python, Flask, and Waitress, bundled into the executable at packaging time. These components run locally as part of the Software and do not independently communicate with any external service. The Software does not include any third-party analytics, advertising, or telemetry software development kit.

7. Design Principle Relevant to Data Integrity

The Software is built around a “refuse or flag, never guess” principle: every match it proposes carries a confidence tier, and any case it cannot resolve with confidence is flagged with a plain-language reason rather than resolved automatically. This principle governs how the Software treats the data it is given — it does not silently alter, discard, or resolve ambiguous data on the user’s behalf.

8. Testing and Independent Review

As of this policy’s effective date, the Software has passed 222 automated tests and has undergone four rounds of independent adversarial audit, with the most recent audit finding zero critical or high-severity issues. This testing addresses correctness of the matching logic and has not separately certified the Software against a formal security standard, such as SOC 2 or ISO 27001. No such certification currently exists for this product.

9. User Responsibilities

A user should run the Software only on a machine they trust, keep an independent backup of source financial data separate from the Software’s output, and review every match and flagged item before relying on it or applying it to their own records, consistent with the Software’s license agreement.

10. Reporting a Security Concern

Anyone who identifies a security issue, or has a question about this policy, may contact Fahmy Project Solutions at the contact address listed on fahmyprojectsolutions.com.

11. Changes to This Policy

This policy may be updated as the Software changes. The Effective Date above reflects the most recent revision. Material changes to network activity, local storage behavior, or third-party components will be reflected here.