IT & Data-Protection briefing

Deployment & runtime

• Runs on-premise on a single Linux host the bank controls — no cloud dependency, no multi-tenant SaaS.
• Small, auditable stack: Python standard library + FastAPI + Uvicorn (served behind the bank's Nginx/TLS). No heavyweight data-science or GIS runtime to vet.
• Runs as an unprivileged service (systemd, User=www-data, memory-capped); state is a single local SQLite file the bank owns.
• Vendor-neutral and portable (ships a PORTABILITY.md; passes a fresh-clone run) — no lock-in to us or any cloud.

Data flows — what (if anything) leaves the box

The built-in analyser (the instant default) makes zero outbound calls. Every external caller below is opt-in and OFF by default, and a single master switch OFFLINE=1 hard-disables all of them.

Data minimisation & privacy (Ghana Data Protection Act, 2012 — Act 843)

• The tool screens property location + loan attributes (asset id, lat/lon, exposure, LTV, optional currency/DSR/sum-insured) — not borrower PII. No names, IDs, phone numbers or account numbers are needed.
• The public demo is wholly synthetic and stores nothing; an ephemeral upload is held in memory only and swept on expiry.
• A saved book lives only in the bank's on-box SQLite; redeploys never overwrite it (the deploy archive excludes the data directory).

Security controls

• Transport: TLS at the bank's Nginx; the app sends HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (SAMEORIGIN), Referrer-Policy and Permissions-Policy on every response. (Full disclosure: the CSP currently allows 'unsafe-inline' for the app's own inline scripts/styles; all reflected parameters are HTML-escaped, so no injection sink was found, and migrating inline scripts to per-response nonces is a tracked hardening item.)
• Accounts: PBKDF2-HMAC-SHA256 password hashing, server-side sessions, Secure/HttpOnly/SameSite cookies, login throttling. No public sign-up — accounts are provisioned on the box.
• Authorisation: role-gated Bank-of-Ghana supervisor actions (issue directive, adaptation verdict); analyst role is read-only; ownership-scoped portfolio access.
• Data integrity: parameterised SQL throughout (no string-built queries); a tamper-evident audit log of security-relevant actions.
• Uploads: type + size caps, streamed parsing, zip-bomb guard on XLSX, per-IP throttling and a session cap; evidence files served nosniff with server-assigned MIME.
• No secrets in the codebase; all endpoints and connector URLs are environment-configured.

Integration surface (fits your existing stack)

• JSON API POST /api/screen — screen one property at the point of application from a loan-origination system (JSON in, JSON out; coordinates travel in the request body, not the query string, so they never land in access logs).
• CSV import/export for a whole book; a machine-readable BoG return (CSV + Word). No proprietary formats.
• A liveness/version probe at GET /health for your monitoring.

Backups, rollback & operations

• Deploy is a reproducible archive → extract → restart; the previous version is a re-extract + restart away (rollback).
• The SQLite state is backed up independently and excluded from the deploy archive, so a redeploy can never destroy a saved book.
• GET /health returns status, version and the offline flag; the service is memory-capped and self-restarts under systemd.

Air-gap operation

• Set OFFLINE=1 for a hard air-gap: the built-in analyser still runs fully (pure local compute); all external callers are disabled.
• The only component that benefits from internet is the browser map basemap, and it degrades to a labelled note (the same data is always in the table) when offline.

What the tool deliberately does NOT do

• No cloud processing of bank data, no multi-tenant storage, no sale or onward sharing of any data.
• No third-party analytics unless the bank explicitly enables it; no borrower PII collection; no black-box scoring — the full methodology and every constant are published in-tool.