rl-docs-hub

Home · Apps · rl-bank-mvp · Architecture

Fake Bank MVP feature inventory and implementation status

Status: Current

This page describes the fake bank as a product/system, not just as a collection of repos.

It covers the current MVP surface across:

rl-bank-api
rl-bank-webapp
rl-bank-mobile-app
rl-bank-mp-webapp
rl-bank-mp-mobile-app

Reality check

This is an internal fake bank preview, not a production-ready banking system.

Important constraints:

customer and staff apps currently rely on preview identity entry rather than a real end-user Auth0 login flow
several flows are GraphQL-backed and real within the fake-bank backend, but only for narrow internal-preview usage
transfers currently support internal account-to-account movement only; no external beneficiary rails are implemented
staff governance is now materially better than before, but broader operational tooling is still incomplete
AWS hosting/infrastructure for the bank is documented and planned, not yet implemented as live IaC

Status legend

Done / implemented — available in the current fake-bank implementation
Partial / preview-only / constrained — works, but with clear MVP or internal-preview limits
Not done yet — not implemented in the current product
Planned / later — intentionally deferred follow-up

MVP feature inventory

Area	Current status	Notes
Customer auth / identity	Partial / preview-only / constrained	Customer web and mobile apps have guarded routes and preview sign-in context, but not a real Auth0 customer login journey yet.
Staff auth / identity	Partial / preview-only / constrained	Staff web and mobile apps also use preview staff identity entry today. Real Auth0 staff login is still pending.
Customer profile / me	Done / implemented	Customer apps resolve a live `publicMe` profile snapshot and show core identity/KYC/status fields. Editing/self-service profile management is not present.
Account application flows	Done / implemented	Customer web/mobile can submit account applications via GraphQL, with live application history, reviewer context, and approved-account outcome visibility.
Card application flows	Done / implemented	Customer web/mobile can submit card applications tied to approved accounts, with live history and issued-card outcome visibility.
Staff review / approval flows	Done / implemented	Merchant portal review panels call admin account/card review queries and mutations, including approval/rejection notes and linked outcomes.
Account visibility / account detail	Partial / preview-only / constrained	Customer apps show approved account outcomes and use live account lists for transfers/card linking, but dedicated rich account-detail views are still thin.
Card visibility / card detail	Partial / preview-only / constrained	Customer apps show owned cards and issued-card outcomes, but lifecycle/detail management is still limited.
Transfers	Done / implemented	Internal transfers between the customer’s own active approved accounts are GraphQL-backed with validation and success/failure handling.
Transfer history / transactions	Partial / preview-only / constrained	Transfer history is visible in customer apps. A fuller transaction ledger experience is not yet exposed as a complete customer-facing product surface.
Permissions / staff governance	Done / implemented	Staff roles/permissions exist in backend, and staff access governance change-request workflow has been rebuilt and landed in API + staff UIs.
Audit / operational visibility	Partial / preview-only / constrained	Audit log models and permissions exist; governance/audit recording is present for staff access changes. Broader operations/risk tooling remains placeholder-level.
Debug tracing	Not done yet	No per-user debug tracing control exists yet.
Notifications / email	Partial / preview-only / constrained	Email/notification modules exist in the API, but customer-facing notification journeys are not documented as a complete live product capability.
AWS preview readiness	Partial / preview-only / constrained	A reasonable AWS-first target architecture is documented, but the bank IaC baseline is still planning-only and not deployed.

Detailed product status by capability

1) Customer auth / identity

Status: Partial / preview-only / constrained

What exists now:

customer web and mobile apps gate protected routes behind an authenticated app state
both apps allow entry of a preview customer label and Auth0 subject
the backend can resolve the supplied identity context for customer-facing queries/mutations

What is still missing:

real Auth0 browser/mobile sign-in flow for customers
production-style callback/logout/origin handling in a live deployed environment
stronger session handling expected from a real banking front end

Practical meaning:

the fake bank can be exercised end-to-end by internal testers
it is not honest to describe customer login as production-ready

2) Staff auth / identity

Status: Partial / preview-only / constrained

What exists now:

merchant portal web/mobile apps use preview staff identity entry
staff identity can resolve through backend staff profile queries
UI navigation is permission-aware after identity resolution

What is still missing:

real staff Auth0 login flow
full operational hardening around session assurance and staff access lifecycle

3) Customer profile / me

Status: Done / implemented

What exists now:

customer apps call publicMe
profile summary includes customer number, full name, email, phone, status, and KYC state
customer home pages use that profile as the top-level identity context

What is still missing:

customer self-service profile editing
preference management, address management, document upload, and richer profile lifecycle

4) Account application flows

Status: Done / implemented

What exists now:

customers can submit account applications in web/mobile
current flows show application history from the backend, not fake local-only mocks
application states include reviewer context and review notes when present
approved applications can surface the created account back to the customer

Current constraints:

application journey is still MVP-focused, not a full regulated onboarding/KYC workflow
no evidence of full document collection, sanctions screening, or complex onboarding policy logic in the product docs

5) Card application flows

Status: Done / implemented

What exists now:

customers can request cards against linked approved accounts
card applications load live history and review context
approved applications can surface the created/issued card outcome
apps clearly treat approved accounts as the next step before card linkage

Current constraints:

card controls are still basic
no richer servicing such as freeze/unfreeze, PIN reset, delivery tracking, or dispute handling

6) Staff review / approval flows

Status: Done / implemented

What exists now:

staff portal supports account-application review listing
staff portal supports card-application review listing
review dialogs support approve/reject decisions
rejection requires a reason in the staff UI
review outcomes refresh linked account/card states back into the product journey

Current constraints:

broader case-management workflow is still light
risk/operations workspace remains incomplete beyond core review actions

7) Account visibility / account detail

Status: Partial / preview-only / constrained

What exists now:

customer apps expose account visibility sufficient for:
- seeing approved-account outcomes from applications
- selecting active accounts for transfers
- selecting funding accounts for card requests
account summary data includes masked account number, product name, status, balance-related fields, and timestamps in the product/backend surface

What is still thin:

no dedicated rich account-detail page with statements, limits, holds, documents, or lifecycle actions
visibility is good enough for preview flows, not yet a fully rounded retail-banking account experience

8) Card visibility / card detail

Status: Partial / preview-only / constrained

What exists now:

customers can list their cards
issued-card outcome can be shown from card applications
card/account linkage is visible

What is still thin:

no mature card-detail/service controls
no broad lifecycle management for activation, replacement, controls, or limits

9) Transfers

Status: Done / implemented

What exists now:

customers can create transfers between their own active accounts
transfer forms use live GraphQL-backed data
the UI shows validation and backend success/failure responses honestly
the product explicitly avoids pretending external transfer rails exist when they do not

Current constraints:

transfers are limited to internal account-to-account movement inside the fake bank preview
no external beneficiaries, FAST/PayNow/wire/payee management, or scheduled transfers are shown as implemented

10) Transfer history / transactions

Status: Partial / preview-only / constrained

What exists now:

customer apps show live transfer history with status, reference, timestamps, source/destination accounts, and failure reasons when present
transaction and transfer entities/models exist in the backend design

What is still missing:

a complete customer transaction ledger experience across all account activity
richer filters, merchant/card transaction history, statement exports, and reconciliation-grade history tools

11) Permissions / staff governance

Status: Done / implemented

What exists now:

backend has staff roles, permission enums, and role-to-permission resolution
operations role includes employee-management capability
staff access governance rebuild has already landed across API + web + mobile staff surfaces
governance workflow now supports:
- access change requests
- create/list/review actions
- approval/rejection handling
- duplicate/no-op/self-review protections
- audit logging

Why this matters:

this moved the fake bank from loosely implied staff powers into a more credible governed-access model for internal preview

12) Audit / operational visibility

Status: Partial / preview-only / constrained

What exists now:

audit log domain objects, actions, actor types, and entity types exist
audit-read permission exists
governance-related auditing is present for the new staff access workflow
staff portal includes a risk/operations placeholder area protected by audit-related permissions

What is still missing:

a broad operational console for investigations, alerts, workflow queues, and cross-feature audit visibility
fuller production-style observability for business operations

13) Debug tracing

Status: Not done yet

Current state:

no implemented per-user debug tracing control was found in the current fake bank product

Planned / later direction already identified:

admin-only enablement
expiry / TTL
audit logging
structured logs and correlation IDs
careful handling of secrets and PII

This should remain documented as planned, not implied as present.

14) Notifications / email

Status: Partial / preview-only / constrained

What exists now:

notification and email modules/entities exist in the API codebase
notification types include email in the backend model

What is still unclear or incomplete at product level:

no clear customer-facing notification center or polished email journey was found in the current customer/staff app docs
application decision notifications, transfer notifications, and delivery guarantees should not be treated as fully shipped product behaviour yet

15) AWS preview readiness

Status: Partial / preview-only / constrained

What exists now:

a sensible AWS-first target architecture is documented for the fake bank MVP
the design covers ECS Fargate for API, S3/CloudFront for web apps, Route53/ACM, secrets/config delivery, and observability direction

What is not done yet:

baseline bank IaC has not been implemented yet
deployment is not yet a completed production-like AWS setup
database choice and some deployment prerequisites are still unresolved

Practical meaning:

the fake bank is architecturally pointed toward AWS, but not yet AWS-live in the way the documentation would need to claim full preview readiness

Done vs not-done summary

Done / implemented now

customer profile/me snapshot
account application submission + history + approved account outcome visibility
card application submission + history + issued card outcome visibility
staff review/approval flows for account and card applications
internal customer transfers between active own accounts
transfer history visibility
staff permissions model and governed access-change workflow

Partial / preview-only / constrained now

customer auth
staff auth
account detail experience
card detail experience
broader transaction history experience
audit/operations tooling
notifications/email product journeys
AWS readiness

Not done yet

per-user debug tracing
real external transfer rails
mature self-service profile management
mature card servicing controls
complete operational/risk tooling

Planned / later

per-user debug tracing with TTL, audit, and correlation support
richer operational observability
fuller production-style auth flows
eventual AWS deployment baseline when infra work is intentionally resumed

Recommended wording for stakeholders

If someone asks “what is the fake bank MVP today?”, the honest answer is:

The fake bank already supports core internal-preview journeys for customer profile lookup, account and card applications, staff review/approval, governed staff access, and internal account-to-account transfers. It is still constrained by preview identity login, thin account/card detail servicing, incomplete operations tooling, no per-user debug tracing, and planned-but-not-yet-built AWS infrastructure.