How the ArchenFrame™ Banking App Works

ArchenFrame™ Banking is delivered as a downloadable ZIP evaluation package containing a local Streamlit-based workbench, sample CSV files, and evaluator guidance documents. After unzipping the package, the evaluator runs the app locally by double-clicking run_app.bat or by launching python -m streamlit run app.py from PowerShell. During local evaluation, uploaded CSV data remains in the evaluator’s environment. ArchenFrame™ does not collect uploaded customer CSV data from the local workbench.

Step 1: Start with the sample data. The recommended first step is to run the app locally, upload the included sample_banking_customer_data.csv, select Full Banking Evidence Package, and review the generated evidence flow. This lets the evaluator see the app working before preparing institutional data.

Step 2: Review the data guidance files. The ZIP includes the app, sample CSV files, Evaluator_Guide.md, Customer_Data_Request.md, and Subdomain_CSV_Input_Map.md. These files explain how to prepare data, align CSV columns, understand required fields, and avoid guessing which inputs the app needs.

Step 3: Map internal CSV fields to recognized app fields. Evaluators can use Customer_Data_Request.md to review recognized CSV fields, accepted alternate column names, expected data types, and anonymization expectations. They can then use Subdomain_CSV_Input_Map.md to see which fields are most relevant to each banking subdomain, including transaction path stability, fraud/AML/semantic integrity, clearing/settlement/reconciliation, liquidity/leverage/contagion, authority/governance/model risk, banking cyberstability, and post-quantum cryptographic resilience.

Step 4: Upload and validate the CSV. A bank’s internal CSV exports may not initially match the app’s preferred field names. Rather than creating a dead end, the app includes schema validation. When a CSV is uploaded, the workbench identifies which fields were recognized, which alternate names were mapped, and which fields may be missing.

Step 5: Adjust and rerun if needed. The evaluator can rename columns, use accepted alternate field names, prepare a cleaner export, or adjust the CSV using the included guidance files. The recovery path is straightforward: review the map, align the CSV, upload the data, validate the schema, then generate the evidence report.

Step 6: Review the evidence flow. The app organizes results into customer data schema validation, executive evidence summary, banking evidence charts, triggered knob-to-node mapping, dynamic banking node-state evaluation, propagation-path mapping, recommended pilot package, and downloadable Markdown or PDF reports.

Step 7: Use the report for review, not automatic certification. The result is not an automatic compliance certification. It is a regulation-aware evidence package that helps risk, audit, compliance, cyber, model-risk, treasury, operations, cryptographic-governance, and executive teams evaluate where pressure appears, how it may propagate, which nodes and control pathways are affected, and where additional strengthening may be needed.