Skip to content
Independent build

Virtual Banking API

A money transfer that fails halfway is worse than one that never starts. This project is about the halfway case.

A wallet account screen on a phone: card balance, add, send and receive actions, and a list of recent transactions.

The interface above is a presentation mockup of the product, not a screenshot captured from a running system. The interface compositions further down this page are built from the platform’s real module structure — these are private client and commercial platforms.

Role
Full-stack engineer
Year
2025
Status
Independent build
Category
Backend

A fintech-style digital wallet — a client interface for accounts, cards and transfers, over an ASP.NET Core system with OTP authentication, multi-step KYC verification, a full transaction lifecycle with fund reservation and idempotency, fraud triggers, batch payroll and audit logging — built on a Clean Architecture codebase.

The problem

Financial software is judged entirely on its failure paths. A retry that charges twice, a transfer that debits without crediting, a fraud rule that only runs on the happy path — each is a correctness bug that costs real money.

The outcome

A transaction lifecycle that is explicit about every state it can be in, with idempotency keys and fund reservation making retries safe by construction.

Stack

  • ASP.NET Core
  • C#
  • Clean Architecture
  • EF Core
  • SQL
  • JWT
  • REST API

Services

Back to all work

The transaction lifecycle

The wallet screens are the easy half. What decides whether this works is the state machine underneath them — so that is what the case study spends its time on.

  1. 01

    Pending

    Created and validated. Funds are reserved against the source account so the same balance cannot be spent twice.

  2. 02

    Processing

    Executed under an idempotency key, so a retried request resolves to the same transaction rather than a second one.

  3. 03

    Completed

    Reservation is settled, balances are final, and the audit log records who and what.

  4. 04

    Failed

    Reservation is released and the account returns to a known state. Failure is a designed outcome, not an exception nobody handled.

Every transaction occupies exactly one of these states, and every transition is recorded.

Identity and controls

  • OTP and multi-step KYC

    Onboarding is staged, with admin approval gating the transition from a registered identity to an operational account.

  • One account, many cards

    Savings and regular card types carry different rule-based spending constraints against the same underlying balance.

  • Fraud triggers and freeze

    Suspicious patterns can freeze an account, which stops activity without destroying the record needed to investigate it.

  • Batch and scheduled operations

    Payroll batches and scheduled transfers reuse the same lifecycle, so a bulk run has the same correctness guarantees as a single transfer.

Architecture

  • Domain

    Accounts, cards, transactions

    • Entities
    • State machine
    • Spending rules

  • Application

    Use cases and validation

    • Transfer
    • KYC
    • Payroll batch
    • Fraud evaluation

  • Infrastructure

    Persistence, audit, exports

    • EF Core
    • Audit log
    • CSV export
Clean Architecture — financial rules stay in the domain, isolated from transport and persistence.

Next case study

Building something in this space?

I am available for a limited number of projects. Tell me what you are working on.

Start a project