Skip to content

FleyLab Family Finance — one clear view across banks

Read-only account, card, and household finance intelligence with explicit consent at every layer.

FleyLab Family Finance — one clear view across banks
Client
In-house Regulatory Sandbox concept
Year
2026
Role
Product, mobile, security, and Open Banking architecture
Stack
TypeScript Expo Node.js PostgreSQL

Problem

People who use several banks cannot answer simple questions without switching between apps: how much is available, which card funded a purchase, when a credit obligation is due, and what the household is spending as a whole. Bank applications are necessarily centred on one institution. A family view is harder still because every account belongs to a specific customer and must never be exposed merely because someone joined a shared group.

Approach

FleyLab creates a source-first financial view. Every account, balance, and transaction carries its bank and source account. A user can open a card or account to see its current balance, payment history, credit limit, and repayment facts when the provider supplies them. Missing card identifiers or due-date fields are shown as unavailable — never guessed.

Family Finance adds a second, separate permission layer:

bank → account owner’s bank consent → FleyLab → owner’s household sharing permission → selected adult recipient

Each adult registers and authenticates independently, connects only their own bank relationship, and then chooses a recipient, accounts, information level, purpose, and expiry. Balance-only, category summary, obligations, transaction detail, and full analytics are separate scopes. Membership itself grants no financial access, and the owner can revoke a grant at any time.

Product experience

  • Home: total available cash, upcoming obligations, and the few changes requiring attention.
  • Activity: one transaction feed with bank, account, card when available, data owner, and sharing audience visible on every item.
  • Money: clickable bank accounts and cards with balances, history, limits, recurring commitments, and source freshness.
  • Access: bank consents and household grants shown separately, with a persistent “who can see what” view and immediate revocation.

The interface is intentionally calm: one primary answer per screen, plain language, and progressively disclosed detail instead of a dense dashboard.

Safety and Sandbox boundary

The first proposed Sandbox phase is for independently authenticated adults only. It is read-only: no payment initiation, custody, transfers, lending, investment execution, or collection of bank passwords, PINs, or CVVs. Joint accounts, additional-card rights, and minors remain outside Phase 1 pending specific guidance from the Central Bank of Azerbaijan and participating banks.

The current build is a local synthetic-data prototype and application-preparation concept. It does not connect to bank production systems and does not claim Sandbox admission, regulatory approval, or endorsement.

Intended outcome

The product tests a different unit of financial understanding: not just one bank’s customer view, but a consent-driven household view assembled from legally separate customers and multiple institutions. Success is measured through correct source attribution, zero unauthorised reads, reliable revocation, user comprehension, and sustained read-only reliability — not through payment volume.