NetBanking Login

Sign in to view your accounts, convert currency and manage cards.

● Secure Customer Login

Customer ID / User name *

Password *

Demo credentials — printed here on purpose User aditi.sharma Password demo1234
Both fields are prefilled. This is a mock authentication screen: the credentials are hardcoded in the page, checked in the browser, and match nothing real. Never type a real password into any prototype.

Reviewing applications? Staff login ›
Not a customer yet? Open an account ›

No credential is stored, hashed or transmitted. There is no server, no session cookie and no storage API in use. Signing in sets a variable in this browser tab and nothing else.

Staff Login

Internal access for compliance and operations personnel.

● Back-Office Access

Staff ID *

Password *

Role

Demo credentials — printed here on purpose Staff ID compliance.officer Password admin1234
Hardcoded and checked in the browser. The role selector changes the name written into audit entries — it grants nothing, because there is no authorisation layer to grant.

Not staff? Customer login ›

A production back office would sit behind enterprise SSO with enforced multi-factor authentication, IP allow-listing and privileged-access logging. None of that is present here; this screen exists to demonstrate where the boundary sits in the system design.

Access denied

You do not have permission to view that page with your current session.

In the prototype this check runs in the browser and is trivially bypassable — it demonstrates where role separation belongs in the design, not a security boundary. A production build enforces this server-side on every request, and never relies on the client hiding a page.

Account Summary

Consolidated position across your multi-currency ledgers, with the most recent settlement activity. Figures are illustrative and do not represent any real holding.

Relationship Overview

My Accounts

4 currency ledgers

Account number	Ledger	Currency	Available balance

Indicative Rates

Illustrative table. Not live market data.

Security Advisory

Never share your password, transaction password or OTP with anyone — including anyone claiming to be from the institution.

No legitimate bank will ever ask you to make a payment to unlock, verify or release funds already shown in your account. Any such request is a fraud attempt.

Recent Transactions

Last 8 entries — all ledgers

Date	Particulars	Status	Amount

Status values follow the six-state model defined in the fund transaction security policy: Pending, Processing, Completed, Failed, Rejected and Under review. Entries marked Under review are held for compliance screening before settlement.

Statements & Receipts

Full payment history across every ledger, with a downloadable statement and a dated receipt for each entry.

Account Statement

—

Ledgers Covered

—

Account number	Currency	Ledger	Available balance

Payment Summary

—

Ledger

Status

Corridor

Direction

Value date	Booked	Reference	Particulars	Corridor	Status	Amount	Receipt

Entries are ordered by value date — the date an entry takes economic effect — with the booking date shown alongside as the moment the record was created. The two differ when a correction or a late correspondent confirmation is posted with an earlier value date. An entry that has been reversed stays on the statement, struck through and flagged, alongside the contra entry that cancelled it; nothing is ever removed.

Downloads are generated in your browser from the in-memory ledger and saved straight to your device — nothing is requested from or sent to a server. The statement exports exactly the rows currently shown by the filters above, carrying both dates and any ledger flag.

Nomination

Register who receives the balance on your accounts. Nomination applies across the whole relationship, and shares must total exactly 100% to be effective.

Allocation

—

Registered Nominees

—

Nominee	Relationship	Date of birth	Guardian	Share	Action

A nominee under 18 cannot receive funds directly, so a guardian must be named at registration. The guardian holds the entitlement until the nominee reaches majority.

Add a Nominee

Confirmation required

Nominee name *

Relationship

Date of birth * A nominee under 18 requires a guardian.

Nominee address *

Nothing here leaves your browser.

Nomination History

—

Every registration, variation and cancellation is recorded. A nomination change is never actioned over the telephone, and nobody from the institution will ask you for a password or one-time code to make one on your behalf.

Receive International Payment

Your designated foreign-currency collection accounts, and the gateway reference a remitter must quote so an incoming payment reconciles to you automatically.

Your gateway ID is issued free and is never a condition of release

A gateway ID is a routing reference the institution issues with your collection account. It exists so an inbound credit can be matched to you without manual intervention. It is free, it is already shown below, and it is never purchased, renewed or activated.

If a payment arrives without it the funds are not lost — they sit in the unallocated queue below and are matched to you once the reference is confirmed. No payment, fee, deposit or “clearance charge” is ever required to receive money that is already on its way to you. Anyone who tells you otherwise is running a fraud, whatever documentation they produce.

Your Collection Accounts

Foreign currency only

Currency	Account number	SWIFT / BIC	Gateway ID	Correspondent	Status

The domestic INR ledger is not listed — rupee credits arrive by IFSC through the domestic clearing network and need no gateway reference. See Domestic.

Remittance Instructions

Send these to your payer

Currency to receive

Unallocated Inbound Credits

—

Received	Remitter	Quoted reference	Amount	Action

A credit that quotes no reference, or one that does not match, is held here rather than being credited to the wrong account. Supplying the correct gateway ID allocates it — at no charge.

Simulate an Incoming Payment

Demo control

Stands in for a correspondent bank delivering a payment message. There is no network here, so nothing genuinely arrives — this posts a mock inbound credit so both outcomes can be demonstrated: a correctly referenced payment that credits straight through, and an unreferenced one that lands in the unallocated queue.

Currency

Amount *

Remitter

Gateway reference quoted

Credits the ledger only when the reference matches.

Domestic Transactions

Rupee settlement within India, routed by IFSC. No currency conversion applies and no cross-border commission is charged.

₹

India · INR corridor

Settled through the domestic clearing network using the beneficiary’s IFSC. Because both legs are in rupees there is no exchange rate and no conversion spread — the amount debited is the amount the beneficiary receives, less any applicable service charge.

Rupee Entries

—

Value date	Reference	Particulars	Routing	Status	Amount (INR)	Receipt

New domestic transfer All corridors

A transfer counts as domestic when the beneficiary is in India and both legs settle in rupees. Anything that crosses a border or converts currency appears under International.

International Transactions

Cross-border settlement routed by SWIFT, with currency conversion and the standard commission applied per the published schedule.

⇄

Cross-border · multi-currency corridors

Settled through correspondent banks using the beneficiary’s SWIFT/BIC. Where the debit ledger and the beneficiary account differ in currency, conversion is applied at the quoted rate and the standard 2% commission is deducted before settlement. Third-party correspondent charges, where levied, are passed through at cost.

Cross-Border Entries

—

Value date	Reference	Particulars	Corridor	Routing	Status	Amount	Receipt

New international transfer Currency exchange All corridors

Amounts are shown in the currency of the debit ledger. Conversion detail and commission for any entry appear on its receipt.

Messages & Alerts

Secure messages from the institution. Delivery is in-app only — the prototype integrates no email, SMS or push provider.

Inbox

—

About Secure Messages

What a genuine message will never ask for

The institution will never ask you — by message, email, telephone or any other channel — for your password, transaction password or one-time code, and will never ask you to make a payment to release, verify or unlock funds already shown in your account.

A message making either request did not come from the institution, however convincing the branding. Messages here are read-only notices; no message in this inbox can ask you to authorise anything.

Manage Beneficiaries

Register, review and remove the accounts you can transfer to. A newly added beneficiary enters a cooling-off period before it can receive its first settlement.

Registered Beneficiaries

—

Beneficiary	Account	Corridor	Type	Status	Action

Only beneficiaries marked Verified can be selected on Transfer Funds. This is control layer 4 of the security model — holding a newly registered payee before its first settlement limits what a compromised session can do.

Add a Beneficiary

Confirmation required

Beneficiary name *

Account number *

Beneficiary country

Account currency

Transfer type

SWIFT / BIC code * Eight or eleven characters — bank, country, location, optional branch.

IFSC code * Eleven characters — four-letter bank code, then 0, then a six-character branch code.

Reference / nickname

Account numbers are masked on save — only the last four characters are retained for display.

Nothing entered here leaves your browser. The list is held in memory and a page reload restores the seeded beneficiaries.

Why New Beneficiaries Are Held

Verification is never accelerated by a payment

A newly registered beneficiary is held before its first settlement so that an attacker who gains access to a session cannot immediately add their own account and drain the balance. The hold clears on the institution's own schedule, through its own checks.

No legitimate institution will offer to lift that hold in exchange for a fee, a transfer, or a "verification payment", and none will ask you for your password or one-time code to release it. A request of that kind is a fraud attempt regardless of who appears to be making it.

Transfer Funds

Authorised transaction journey, implementing the eleven-step flow defined in the fund transaction security policy. No money moves — settlement is simulated against the in-memory ledger.

Select a registered beneficiary. Beneficiary verification and the post-registration cooling-off period are control layer 4 of the security model.

Add / Manage Beneficiaries Policy step 3 — Select beneficiary. You choose the payment source (ledger or card) on the next step.

Policy Flow Mapping

11 steps

Steps 1–2 are satisfied by the login you completed to reach this page. Steps 3–11 are the five stages above. The full control model is documented under Security & KYC.

Account Types

Five account classes — one corporate and four individual tiers — each with a stated minimum opening requirement and a corresponding service segment.

Available Account Classes

5 classes

Segment	Account class	Minimum opening	Action

Note on the corporate figure. The corporate requirement is quoted in Indian Rupees while all individual tiers are quoted in US Dollars. Because the two are held in different currencies, the schedule is not ordered by a single comparable amount — the data model stores openingAmt alongside an explicit currency field per tier rather than a single numeric column, so conversion happens at the point of comparison rather than being baked into the stored figure.

Account Opening Process

7 stages

Stages 1–2 are demonstrated on Open an Account and stages 3–6 in the Compliance Console. A submission creates a mock queue record and nothing more — no identity documents are requested or stored, no funds are collected, and no real account is provisioned at any stage.

Currency Exchange

Conversion quote between supported currency ledgers, showing the gross converted amount, the applicable commission, and the net amount credited to the beneficiary.

Conversion Calculator

Indicative rates — not live market data

Amount to convert *

From currency

To currency

Rates are a fixed illustrative table held within this page — not live market data. No external rate provider is contacted. Quotes are indicative only; no transfer is initiated and no beneficiary is notified.

Conversion Quote

You send—

Applicable rate—

Gross converted—

Less commission (2%)—

Beneficiary receives—

Settlement Sequence

On the commission rate. The currency exchange policy treats the exchange commission as separate from the 2% standard transaction commission and does not fix it at a single published rate. The 2% used above is an illustrative stand-in so the calculation can be demonstrated end to end; a production implementation resolves the rate per corridor from the fee schedule.

Cards & Digital Payments

Three card products issued against the account, each available in digital and physical form. Card artwork and numbers below are illustrative.

Issued Cards

3 products

Limits & Service Terms

Card	Capability	Stated limit

Figures marked sample are invented for the prototype; the ATM withdrawal cap and the high-value transaction ceiling are carried from the source card policy. The prototype names no card network or issuing partner.

Payment Ecosystem

Open an Account

Application for a new account. A valid referral code is required before the form opens.

Use fictional details — never your real personal information

This form asks for the kind of detail a real account opening requires: date of birth, addresses, telephone numbers, income and employment. It is a design prototype. There is no server, no database and no network capability of any kind in this file, so nothing typed here is stored or transmitted — it lives in this browser tab and is discarded on reload.

Every field is prefilled with sample values and is meant to stay that way. Please do not substitute your genuine details.

Step 1 — Referral Code

Required to continue

Referral code * Format 2WF-XXXXXX. Demo codes: 2WF-DEMO01, 2WF-PART22, 2WF-STAFF7.

The application form opens once the code is recognised.

Step 2 — Applicant Details

Full name *

Father’s / husband’s name *

Date of birth * Applicant must be 18 or over.

Highest qualification

Step 3 — Address

Communication address is mandatory

Communication address *

Permanent address is the same as the communication address

Permanent address *

Official address Optional — the address of your employer or business premises.

Step 4 — Contact

Personal mobile * Digits, spaces, and a leading + only.

Official mobile

Landline

Email *

Step 5 — Business Profile

Organisation / company name *

Annual turnover

Occupation

Step 6 — Personal & Assets Profile

Annual income

Residence

Vehicle

Step 7 — Account Requested

Country of residence

Account class requested

Declared purpose of account

Reason for opening an account in another country *

Supporting detail * Explain the connection to that jurisdiction. Recorded on the application and read by the compliance reviewer.

Step 8 — Declaration

* I have read and accept the Terms & Conditions, the Privacy Policy and the Fees & Service Charges schedule. I confirm the information given above is accurate and that I am applying on my own behalf.

Creates a queue record only. No account is opened and no funds are collected.

The requested class determines the stated minimum opening requirement shown on Account Types. That requirement is documentation — the prototype never asks an applicant to transfer it.

What Happens After Submission

7 stages

Stages 1–2 are represented by the form above. Stages 3–6 are carried out by a reviewer in the Compliance Console, where an application can be moved to review, approved or rejected. Stage 7 is the live account shown on Account Summary. Identity verification runs through eKYC.

eKYC Verification

Identity verification stage of account opening. This screen models the process — the checklist, the states each document moves through, and the reviewer adjudication that follows — without collecting any document.

Use test images — never a real Aadhaar, PAN or photograph

This page has no network capability whatsoever — the file contains no fetch, no XHR, no WebSocket, no form action and no server of any kind. A selected file, a captured photograph and a drawn signature are all shown as local previews and held only in this browser tab; closing or reloading the page discards them. Nothing is uploaded, because there is nowhere to upload to.

Even so, please use dummy images rather than your genuine documents, and a scribble rather than your real signature — a specimen signature is a security credential in its own right. Aadhaar collection is restricted by law to UIDAI-authorised channels, and a production build should never hold the document at all: it verifies through an authorised KYC User Agency and stores only a masked reference and a verification assertion.

Beyond capture, the prototype implements what a system-design review assesses: the document checklist, the state machine each item moves through, the reviewer adjudication in the compliance console, the audit trail, and the rule that an account cannot be approved until identity verification passes.

Verification Progress

—

Select Application

Application reference

Submit an application on Open an Account and it appears here for verification.

Required Documents

—

Simulated capture records a filename, a size and a timestamp against the application so the downstream states can be demonstrated. It does not open a file picker or a camera, and no bytes are read.

Video KYC Appointment

Scheduled, not conducted

Video KYC is modelled as a booked appointment rather than a live session. Building the session itself would mean requesting camera and microphone access from anyone who opens this file, which is exactly the capability the prototype withholds. The control is documented under Security & KYC as layer 7.

Compliance Console

Back-office queue for account applications. A reviewer inspects a submission, advances it to review, and either approves or rejects it — every transition writing an audit entry.

Viewing as: Compliance officer — mock role, no authentication. The prototype has no login, no roles table and no access control; the console is reachable from the navigation like any other page. A production build would place this behind authentication and restrict it to reviewer accounts. Queue state is held in memory and resets on page reload.

Queue Summary

Live counts

Applications

—

Reference	Applicant	Requested class	Submitted	Status	Action

Select Review on any row to expand the full submission, its stage position and its audit trail. Approving or rejecting is a state change on an in-memory record — no account is provisioned, no applicant is notified and no funds move.

Operations Console

Work awaiting the back office, across every queue. Figures are live against the in-memory state.

Your Session

—

Ledger adjustments and customer-data amendments cannot be authorised by the officer who raised them. Sign in under the other staff role to complete a pending item.

Controls In Force

✓ Dual control on ledger adjustments and identifier changes
✓ Append-only registers — no entry is edited or deleted
✓ Account numbers frozen while value is in flight
✓ Approval blocked until eKYC verification passes
✓ Value date backdatable; booking date system-set

Recent Back-Office Activity

—

Drawn from the application audit trails, the adjustment register and the customer-data maintenance register. This prototype holds it in memory; a production console reads it from an immutable event log.

Customer Messaging

Compose and dispatch secure messages and service notifications to account holders. Delivery is in-app only.

In-app delivery only. No email, SMS or push provider is integrated, so nothing sent here leaves the browser. Messages are one-way notices: the composer cannot create a message that asks a customer to authorise a payment or disclose a credential, because a bank that sends such messages trains its customers to fall for the ones that are not from it.

Compose

Recipient

Sent Messages

—

Sent	Recipient	Subject	Category	Priority	Status	Action

Ledger Adjustments

Post corrections and value-date amendments against the customer ledger under dual control. A posted entry is never edited in place — it is reversed and re-posted, so the original record survives.

Why entries are reversed rather than edited

A ledger is append-only. Silently rewriting a posted transaction destroys the record that a regulator, auditor or customer relies on, and a system that permits it cannot prove what actually happened. So a correction here posts a contra entry that cancels the original and a fresh entry carrying the corrected figures — both remain visible on the statement, and the original is flagged rather than removed.

Backdating is supported through the value date, not the booking date. The value date is when an entry takes economic effect and may legitimately sit in the past — a correspondent confirming late, a correction to a mis-keyed effective date. The booking date is when the record was created and is set by the system, never by the operator. Both appear on the statement, which is what makes a backdated entry auditable rather than deniable.

Post an Adjustment

Requires authorisation by a second officer

Original entry *

Adjustment type

Reason code *

Value date * May be backdated. Cannot be in the future or before the account opened.

Reason narrative * Recorded verbatim on the adjustment register and the audit trail.

Creates a pending item. Nothing reaches the ledger until a second officer authorises it.

Awaiting Authorisation

—

Raised	Type	Entry & reason	Value date	Raised by	Action

Dual control. An adjustment cannot be authorised by the officer who raised it. Sign in under the other staff role to authorise a pending item — the prototype enforces this by comparing the role on the session against the one recorded on the item. A production system enforces it against user identity, not role, and logs both parties against the posting.

Adjustment Register

—

Reference	Type	Entry & reason	Value date	Booked	Status	Maker / checker

The register is append-only: entries are never edited or deleted, including rejected ones. It is the record that makes every backdated posting attributable to a named officer and a stated reason.

Customer Data Maintenance

Amend the identifiers held against a customer record — customer ID, account numbers and PAN — under dual control, with the previous value retained.

Identifiers are amended, not overwritten

A customer ID and an account number are what money is directed to. Changing one silently is how a back office becomes the weak point in a payment chain, so every amendment here records the value before and after, the officer who raised it, the officer who authorised it, and a stated reason. The register is append-only and no entry can be edited or removed once written.

An account number cannot be amended while value is in flight on that ledger. If an entry is processing or held for review, the amendment is refused until it settles — a number that changes underneath a pending settlement is how funds reach the wrong place.

Current Record

—

Identifier	Current value	Notes	In flight

Propose an Amendment

Requires authorisation by a second officer

Identifier to amend

Current value

New value * —

Reason code *

Reason narrative * Retained permanently on the maintenance register.

Nothing changes on the record until a second officer authorises it.

Awaiting Authorisation

—

Raised	Identifier	Change & reason	Raised by	Action

Dual control. An amendment cannot be authorised by the officer who raised it. Sign in under the other staff role to authorise a pending item.

Maintenance Register

—

Reference	Identifier	Before	After	Reason	Status	Maker / checker

Every amendment ever raised stays here, including rejected ones. The previous value is never discarded, so an identifier can always be traced back through its history.

Fees & Service Charges

Standard charge schedule applied to eligible transactions. Charges are deducted at settlement and itemised on the transaction ledger.

Charge Schedule

7 rules

Transaction type	Charge	Notes

Worked Examples

Transaction	Rate	Commission	Net settled

Internal transfers between two 2 Way Fund accounts carry no transaction charge. Third-party correspondent charges and statutory taxes, where applicable, are passed through at cost and shown separately.

Security & KYC Architecture

Reference documentation for the authentication and compliance model. This page is explanatory only — it contains no forms, no capture of any kind, and makes no network calls.

Control Layers

8 layers

Authorised Transaction Flow

11 steps

Restriction & Restoration

Design reference — not implemented

Shown as a static diagram to document how a lockout would be modelled. No lockout logic, attempt counter, or restoration gate exists in this prototype.

Design Principles

Verification and payment are independent processes

Customers should never provide confidential authentication credentials simply because someone claims that doing so is necessary to unlock, verify, or secure an account.

A legitimate financial system never requires a payment, a transfer, or a fee to lift a restriction on funds that are already shown as available. Identity re-verification restores access; it is never priced. Any flow that couples the two is a fraud pattern, not a security control — which is why the restriction diagram above is documentation and nothing more.

Intentionally not implemented

The following are described in the source policy documents but are deliberately absent from this prototype, because building working versions would make the demo capable of collecting real credentials or documents from anyone who opened it:

Credential capture — no login form, password field, or transaction-password entry anywhere in the file
Biometric / liveness capture — no camera access, no video KYC session, no media-device request
Identity document upload — no file input and no document storage
OTP delivery — no SMS or email provider is integrated; OTP appears only as a labelled step in the diagrams
Pay-to-unlock gate — no flow in which a user must pay or re-verify to release funds already shown as available

How onboarding is modelled instead

A real institution performs identity and business verification at stage 3 of account opening, and video KYC on re-verification triggers. Building either would mean putting a document upload and a camera capture behind a page that looks like a bank — so the prototype models the decision without the collection.

The application on Open an Account asks only for a name, a contact email, a country, a requested account class and a declared purpose. It requests no identity number, no date of birth, no address, no telephone number, no password and no document. Verification appears in the Compliance Console as a reviewer state transition with an audit entry — which is what the system design actually needs to demonstrate — rather than as a working intake for personal data.

The eKYC screen carries this through: it presents the document checklist, the state each item moves through, the reviewer adjudication and the rule that no account is approved until identity verification passes — with simulated capture in place of any file input or camera. Video KYC appears there as a booked appointment rather than a live session, for the same reason.

The application is also never gated behind a payment. The stated minimum opening requirement is shown to the reviewer as documentation; at no point is an applicant asked to transfer it, and approval does not depend on it.

Company Profile

2 Way Fund International is a fictional international payments institution used as the subject of this system-design prototype.

At a Glance

Founded

2013

Headquarters

Paris, France

Industry

International payment services

Currency ledgers

USD · EUR · INR · GBP

“Connecting Countries. Converting Currencies. Enabling Global Payments.”

Payment Corridor

A payment originates in one jurisdiction, is converted through the exchange ledger, and settles to a beneficiary account in another. Every leg is subject to the commission schedule and the compliance controls documented under Security & KYC.

About This Prototype

Scope

A single-file design prototype covering twelve routes with no build step and no backend. All seed data is held in one object shaped to the intended relational model — User, Balance, Transaction, Card, AccountTier, FeeRule and Application — so the presentation layer can be ported to a React client and a REST backend without reworking the views.

Routes carry an access level of public, customer or admin, and the router enforces it: signing in as a customer hides the compliance console from the tab bar and blocks it by URL, and vice versa. That check runs in the browser and is trivially bypassable — it shows where role separation belongs in the design. A production build enforces it server-side on every request.

Onboarding is the one stateful flow: submitting an application on Open an Account appends to an in-memory queue that the Compliance Console reads, and reviewer decisions mutate that record and append audit entries. State is deliberately not persisted — no storage API is used anywhere — so a reload returns the demo to its seeded condition.

Everything shown is fictional. No real entity, client, card network or payment processor is named or integrated anywhere in this file.