rl-docs-hub

Home · Apps · rl-bank-mvp

---

Account detail + history realism slice

Status: Draft, intended to match the next implementation slice after card servicing/activity.

Why this slice

The fake-bank preview already has account applications, approved accounts, transfers, cards, notifications, and activity. What it still lacks is the thing customers and support staff look at constantly in day-to-day banking: a believable account detail surface.

This slice makes approved accounts feel operationally real by adding:

• clearer balance health and account status visibility
• account-level recent transaction history
• simple 30-day inflow / outflow signals
• customer-facing account summaries in both mobile and web

This is a better next step than random feature breadth because it deepens the existing core bank loop: approved account → card linked → transfer activity → account history visible.

Product / feature scope

In scope

• customer can view all approved accounts as a real portfolio, not just application outcomes
• each account shows:
  • product name
  • masked account number
  • status
  • available balance
  • current balance
  • last transaction time
  • linked card count
  • recent transaction count
  • 30-day inflow total
  • 30-day outflow total
• customer can open an account detail panel/page and review recent transactions for that account
• customer home/dashboard can highlight the primary active account with balance and latest activity context
• customer web and mobile apps align on the same account-detail story

Out of scope

• downloadable statements / PDF exports
• cheque handling
• interest accrual engine
• scheduled payments / bill pay
• external bank reconciliation
• dispute workflows
• staff case notes on accounts

Product design

Customer experience shape

• Home should stop showing placeholder account facts and instead show a live account snapshot.
• Accounts should become both:
  • an account application surface
  • a live approved-account portfolio and recent history surface
• account detail should answer common customer questions quickly:
  • Do I have active money-ready accounts?
  • Which account moved most recently?
  • What changed recently on this account?
  • Is my current balance different from my available balance?

UI structure

• account portfolio cards at the top
• selected account detail below or beside it
• recent transactions in reverse chronological order
• concise balance language that is truthful to the fake-bank preview

Business logic and rules

1. Customer may only view accounts that belong to the authenticated customer.
2. Account detail only exposes transactions belonging to the same authenticated customer.
3. Recent transaction metrics should be derived from persisted transactions, not fabricated UI placeholders.
4. 30-day inflow is the sum of positive customer-visible incoming transactions for the account.
5. 30-day outflow is the sum of customer-visible outgoing transactions for the account.
6. Recent transaction count should be a lightweight operational signal, not a separate source of truth.
7. If available balance differs from current balance, UI should present that gap as a balance hold / pending-effect style hint without implying unsupported settlement rails.
8. Closed accounts remain visible historically but should not be promoted as primary transfer-ready accounts.

Technical design summary

API additions / changes

• enrich AccountObject with derived operational summary fields:
  • recentTransactionCount
  • inflowTotal30d
  • outflowTotal30d
  • balanceGap
• continue using publicListMyAccounts and publicGetMyAccount as the account source of truth
• reuse publicListMyTransactions for ledger-style account history in the apps

App additions

• mobile app:
  • home page reads live account summary instead of placeholder account copy
  • accounts page adds approved-account portfolio and selected account recent history
• web app:
  • same core portfolio + selected account history model with desktop-friendly layout

Persistence approach

• no new collection is required for this slice
• derive summaries from existing accounts, transactions, and card counts

Technical architecture / data flow

flowchart LR
  Customer[Authenticated customer] --> App[Customer web/mobile app]
  App --> GQL[rl-bank-api GraphQL]
  GQL --> AccountSvc[Account service]
  GQL --> TxSvc[Transaction service]
  AccountSvc --> AccountDB[(accounts)]
  AccountSvc --> CardDB[(cards)]
  AccountSvc --> TxDB[(transactions)]
  TxSvc --> TxDB
  App --> View[Portfolio cards + account detail + recent transactions]

Flow: account portfolio

1. app queries publicListMyAccounts
2. API returns enriched accounts with balances and derived summary fields
3. app highlights active accounts and chooses a default selected account

Flow: account detail history

1. app queries publicListMyTransactions
2. app filters to the selected account
3. app shows recent entries newest-first with amount, reference, direction, and balance-after context

Permissions / access model

Customer permissions

• authenticated customer may view only their own accounts and transactions
• no staff-only actions are added in this slice

API guard model

• existing GraphQL auth guard remains mandatory
• account ownership checks remain enforced in account and transaction services

Least-privilege impact

• no new AWS IAM permissions are required
• no new external providers are introduced

Notes / exceptions

• IaC / AWS architecture change: none; this is application-layer behavior on existing services
• PBX impact: none