A monorepo replacing RSwitch's email-based transaction reporting with structured, validated uploads, plus integration monitoring, a compliance document repository, and issue tracking.
backend/— FastAPI + SQLModel + PostgreSQL + MinIOfrontend/— React + TanStack Router/Query, no component/chart libraryUI/RDIP Prototype.dc.html— the design and information-architecture reference both apps are built against
v1 is four modules only: Data Ingestion, Integrations Monitor, Compliance Document Repository, and Reporting & Issue Tracking. AI/ML detection, automated API pulls, financial inclusion analytics, and governance are explicitly out of scope for this codebase — governance in particular is a separate, smaller coordination project, not a module here.
cp .env.example .env # optional — sane defaults work without this
docker compose up- Frontend: http://localhost:5183
- Backend API docs: http://localhost:8010/docs
- MinIO console: http://localhost:9003
Every port, credential, and origin docker-compose.yml uses comes from
.env (see .env.example for the full list and what each one does) —
nothing is hardcoded in the compose file itself. Ports default to
non-standard values (5183/8010/9002-9003) to avoid clashing with other
projects' containers that might already be running on this machine;
override any of them in .env instead of editing docker-compose.yml.
CORS_ORIGINS (backend) and VITE_API_URL (frontend) must stay in sync
with FRONTEND_PORT/BACKEND_PORT respectively if you change those —
see the comments in .env.example.
A default admin user is seeded on first backend startup:
admin@rswitch.rw / changeme123. Run the demo seed below for the full
set of accounts across every role.
Two tiers, enforced server-side (not just hidden in the UI):
- Staff (Compliance / Business / Board / Technical) see the whole network. Which staff screens look detailed vs. high-level is a frontend choice tied to the role switcher in the header — Board gets the trend dashboard, everyone else gets the detail tables. There's no backend distinction between staff sub-roles yet.
- Participant logins are hard-scoped to exactly one participant — every endpoint filters to that participant's id server-side regardless of what the client asks for, and the frontend shows only their own submissions, documents, and issues. Participants upload their own transaction files and compliance documents — RSwitch staff can view everything but cannot upload on a participant's behalf; the backend rejects a staff-authenticated upload with 403 even if attempted directly against the API. Status changes and issue tracking remain RSwitch's job.
docker exec <backend-container> python -m app.seed_demo seeds 5
participants with 6 months of real, validated submission history (run
through the actual ingestion pipeline, not fabricated numbers), varied
document/integration/issue states, and one login per role below. Every
password is changeme123.
| Role | Sees | |
|---|---|---|
admin@rswitch.rw |
Technical / Admin | Whole network — full access, seeded automatically even without running the demo script |
board@rswitch.rw |
Board | Whole network — Overview shows the trend dashboard (select "Board" in the header role switcher) |
compliance@rswitch.rw |
Compliance | Whole network — full per-participant detail |
ops@kvu.rw |
Participant | Kivu Commercial Bank only |
ops@aks.rw |
Participant | Akagera Savings & Credit only |
ops@mob.rw |
Participant | MobiPesa Rwanda only |
ops@nym.rw |
Participant | Nyanza Microfinance only |
ops@rus.rw |
Participant | Rubavu Union SACCO only |
The three staff logins are interchangeable for data access (the backend doesn't distinguish staff sub-roles yet) — the header role switcher only changes which screens they see, e.g. Board's trend dashboard vs. Compliance's detail tables. The five participant logins are the ones that matter for access control: each is hard-scoped server-side to just that one institution.