Senior Frontend Interview Guide, Part 14: Financial Applications and Payment Systems

This article is Part 14 of 18 in The Senior Frontend Engineer Interview Guide, and includes 20 interview questions with model answers.

Frontend roles at banks, credit unions, and fintech companies come with domain expectations. You will not be asked to settle payments yourself, but you are expected to know how ACH, real-time payments, and wire transfers differ, why money must never be represented as a floating-point number, what idempotency and double-submission protection mean in a payment flow, how to present statuses and cutoff times honestly, and which regulations and controls shape the user interface. This chapter gives you that domain knowledge with a frontend engineer’s perspective.

How Money Moves: Core Vocabulary

Term	Meaning
Originator	The party that initiates a payment (sender for credits, receiver for debits)
Receiver / beneficiary	The party whose account is credited or debited
ODFI / RDFI	Originating and Receiving Depository Financial Institution (ACH terms)
Clearing	Exchanging payment information and calculating obligations between banks
Settlement	The actual transfer of funds between banks, usually through accounts at the central bank
Payment rail	The network and rules a payment travels on (ACH, RTP, FedNow, Fedwire, card networks)
Push payment	Sender initiates a credit to the receiver (wires, RTP, ACH credit)
Pull payment	Receiver initiates a debit from the payer’s account with authorization (ACH debit, card payments)
Routing number (ABA RTN)	Nine-digit number identifying a US financial institution, with a checksum digit
Available versus ledger balance	Ledger (current) balance includes all posted transactions; available balance subtracts holds and pending debits
Hold	Funds reserved and unavailable, for example on a deposited check or a card authorization
Cutoff time	Deadline for a payment to be processed in a given window or business day
Business day	A day the payment system and bank are open; weekends and federal holidays are excluded for ACH and Fedwire

ACH (Automated Clearing House)

The ACH Network is the US batch electronic payment system governed by the Nacha Operating Rules, with the Federal Reserve (FedACH) and The Clearing House (EPN) as operators. It handles payroll direct deposit, bill payments, account-to-account transfers, and business payments: tens of billions of payments and tens of trillions of dollars per year.

Characteristics

• Batch processing: files of entries are submitted and processed in settlement windows rather than individually in real time.
• Credits and debits: ACH can push money (credit, like payroll) or pull money (debit, like a utility company collecting a bill with authorization).
• Settlement timing: standard ACH settles in one or two business days. Same Day ACH offers multiple daily settlement windows for eligible entries up to $1 million per payment.
• Low cost, which is why it is used for most recurring and non-urgent payments.
• Reversibility: payments can be returned for reasons such as insufficient funds or unauthorized debit, generally within two banking days, and up to 60 calendar days for unauthorized consumer debits. This return risk is a major difference from real-time payments.

Standard Entry Class (SEC) Codes

Each ACH entry carries a code describing the type and authorization method:

SEC code	Use
PPD	Prearranged payment and deposit to consumer accounts (payroll, recurring bills)
CCD	Corporate credit or debit between businesses
WEB	Consumer debits authorized via the internet or a mobile device
TEL	Consumer debits authorized by telephone
CTX	Corporate trade exchange with extensive remittance data
IAT	International ACH transactions

Return and Notification of Change Codes

Code	Meaning	Frontend implication
R01	Insufficient funds	Notify user, retry policy (Nacha limits re-presentments)
R02	Account closed	Ask user to update the account
R03	No account / unable to locate	Account details likely wrong
R04	Invalid account number structure	Validation could have caught it
R05, R07, R10, R29	Various unauthorized debit reasons	Fraud or dispute workflows
C01, C02, C03	Notification of Change (NOC): incorrect account number, routing number, or both	Update stored payee details automatically or prompt the user

Account Verification

Before debiting an external account, platforms verify ownership:

• Micro-deposits: send two small credits (for example, $0.17 and $0.42) and ask the user to confirm the amounts, which takes one to three business days.
• Instant verification through data aggregators (Plaid, Finicity, MX) where the user logs in to their bank.
• Account validation services that check account status in real time.
• Nacha rules require WEB debit originators to use a commercially reasonable fraud detection system, including validating the account the first time it is used.

What the UI Must Communicate for ACH

• Expected delivery date based on cutoff and business days (not “instant”).
• Pending status and the possibility of returns.
• Authorization language for debits (the user is agreeing to allow a debit), often with consent records stored by the backend.
• Recurring payment management: frequency, end date, next payment date, and easy cancellation.

Real-Time Payments: RTP and FedNow

Instant payment systems settle each payment individually, in seconds, 24 hours a day, 7 days a week, 365 days a year.

The RTP Network

Launched in 2017 by The Clearing House, the RTP network was the first new US core payment rail in decades. Key characteristics:

• Instant clearing and settlement, with final, irrevocable payments. The sender cannot claw back a payment; corrections happen through a separate request for return message.
• Credit push only: the payer’s bank sends funds. There are no debits on the rail.
• Request for Payment (RfP): a payee can send a request that the payer approves, which then triggers a credit push, useful for bill payment.
• ISO 20022 messaging with rich remittance data.
• A per-transaction limit set by the network, raised over time (to $10 million in February 2025), with individual banks often setting lower limits.
• Confirmation messages tell the sender the payment was accepted or rejected within seconds.

FedNow

The Federal Reserve’s FedNow Service launched in July 2023. It is also a 24x7x365 instant credit-transfer service with ISO 20022 messaging and request-for-payment support. Its network limit has been raised over time (to $1 million at the end of 2024), and participating institutions set their own lower limits. Banks may join RTP, FedNow, or both, and some route instant payments to whichever rail the receiving bank supports.

UI Implications of Irrevocability

Because instant payments cannot be reversed, the user interface carries a heavier responsibility:

• A clear review and confirmation step showing the recipient’s name (when available, via confirmation-of-payee style checks), amount, and source account.
• Explicit warnings: “Payments sent with RTP are immediate and cannot be cancelled.”
• Scam warnings for risky patterns (new payee, large amount, unusual time), since authorized push payment fraud (the victim is tricked into sending money) is a growing problem for instant rails.
• Step-up authentication for new payees or high amounts.
• Instant, accurate status: “Sent” only after the network confirms acceptance; otherwise “Processing” or “Failed” with reason.

Wire Transfers

Wire transfers are high-value, individual, same-day payments.

Domestic Wires: Fedwire Funds Service

Operated by the Federal Reserve, Fedwire Funds is a real-time gross settlement (RTGS) system: each payment is settled individually and immediately in central bank money, and is final and irrevocable once processed. It operates on business days during defined operating hours (opening in the evening of the prior calendar day and closing in the early evening Eastern Time), with bank-specific customer cutoffs earlier in the afternoon. Fedwire migrated its message format to ISO 20022 in July 2025.

CHIPS (Clearing House Interbank Payments System) is a private large-value system that nets payments to reduce liquidity needs and handles a large share of cross-border dollar payments.

International Wires: SWIFT

International wires typically travel over the SWIFT messaging network between correspondent banks. Each bank is identified by a BIC (Bank Identifier Code, also called a SWIFT code), and many countries use IBAN (International Bank Account Number) for accounts. Cross-border payments may pass through intermediary banks that deduct fees, use foreign exchange conversion, and take one to five business days. SWIFT’s industry migration to ISO 20022 (MX messages) replaced legacy MT messages for cross-border payment instructions, with the coexistence period ending in November 2025. SWIFT gpi provides end-to-end tracking with a unique end-to-end transaction reference (UETR).

Wire Characteristics

• High value, used for real estate closings, business payments, and large transfers.
• Fees for sender and often receiver; international wires may include intermediary and FX fees.
• Irrevocable once sent; recalls require the beneficiary bank’s cooperation.
• Heavily targeted by fraud (business email compromise and real estate wire fraud).
• Subject to sanctions screening (OFAC) and anti-money-laundering controls, which can delay processing.
• Governed by UCC Article 4A for commercial funds transfers, with consumer international remittances covered by the Remittance Rule (Regulation E Subpart B), which requires disclosures of fees, exchange rates, and delivery dates.

UI Implications for Wires

• Collect the right data: beneficiary name and address, account number or IBAN, routing number or BIC, intermediary bank details if needed, purpose of payment, and currency.
• Validate formats client-side (IBAN check digits with mod-97, routing number checksum, BIC structure) while relying on server-side validation as the source of truth.
• Show fees, exchange rate, and estimated delivery date before confirmation (required for consumer remittances).
• Display cutoff times with time zone (“Wires submitted after 4:00 PM ET will be sent the next business day”).
• Require strong authentication and often dual approval for business accounts (maker-checker).
• Present a tracking reference (Fedwire IMAD/OMAD or SWIFT UETR) after submission.

Comparing the Rails

	ACH	Same Day ACH	RTP / FedNow	Fedwire (domestic wire)	International wire (SWIFT)
Speed	1 to 2 business days	Same business day	Seconds	Minutes to hours, same day	1 to 5 business days
Availability	Business days	Business days, set windows	24x7x365	Business days, operating hours	Business days, varies by country
Direction	Credit and debit	Credit and debit	Credit push only (plus request for payment)	Credit push	Credit push
Finality	Returns possible	Returns possible	Final, irrevocable	Final, irrevocable	Final once credited; recalls difficult
Typical cost	Lowest	Low	Low	Higher	Highest
Limits	Varies by originator	$1M per payment	Network limit; bank limits lower	Effectively none at network level	Bank limits
Typical use	Payroll, bills, recurring	Urgent payroll, bill pay	Instant transfers, bill pay, gig payouts	Real estate, large B2B	Cross-border

Interviewers often ask, “A customer wants to send $50,000 to pay for a house closing tomorrow. Which rail?” A good answer: a domestic wire (or instant payment if the receiving bank supports it and the bank’s limit allows it), explaining finality, cutoff times, fraud risk, and the need to verify wiring instructions by phone using a known number.

Representing Money in Code

Never Use Floating-Point for Money

0.1 + 0.2;               // 0.30000000000000004
1.005 * 100;             // 100.49999999999999
Math.round(1.005 * 100); // 100, not 101

Binary floating-point cannot represent most decimal fractions exactly. Errors accumulate in sums and break equality checks and rounding.

Options

1. Integer minor units: store $12.34 as 1234 cents. Simple and exact for addition and subtraction, but you must know each currency’s minor unit exponent (JPY 0, USD 2, KWD 3), and integers above Number.MAX_SAFE_INTEGER lose precision (use BigInt for very large values).
2. Decimal strings in transport: APIs send {"value": "12.34", "currency": "USD"}, which is unambiguous and survives JSON serialization.
3. Decimal libraries for arithmetic: decimal.js, big.js, or dinero.js (which models amounts with currency and scale and provides allocation).

import { dinero, add, allocate, toDecimal } from 'dinero.js';
import { USD } from '@dinero.js/currencies';

const price = dinero({ amount: 10000, currency: USD });   // $100.00
const [a, b, c] = allocate(price, [1, 1, 1]);             // $33.34, $33.33, $33.33 (no lost cent)
toDecimal(add(a, b));                                      // "66.67"

Rounding

Rounding rules are a business decision: half-up, half-even (banker’s rounding, which reduces bias in large datasets), or truncation, and they must match the backend. The frontend should generally display amounts calculated by the backend rather than recompute fees or interest. When the frontend must calculate (a live estimate), label it as an estimate.

Parsing User Input

function parseAmountToCents(input: string, locale = 'en-US'): number | null {
  const normalized = normalizeLocaleNumber(input, locale);   // "1,234.50" -> "1234.50"
  if (!/^\d+(\.\d{1,2})?$/.test(normalized)) return null;
  const [whole, frac = ''] = normalized.split('.');
  return Number(whole) * 100 + Number(frac.padEnd(2, '0'));
}

Parsing via string manipulation avoids floating-point entirely. Validate maximum digits, reject negative and zero amounts where inappropriate, and display the parsed value back formatted so users can confirm what the system understood.

Designing a Payment Flow

A robust payment UI follows a predictable sequence:

1. Select source account (show available balance) and recipient (existing payee or new payee with verification).
2. Enter amount and date (immediate, future-dated, or recurring), with validation against limits and available balance.
3. Choose rail or speed when several are available (standard ACH free, Same Day small fee, instant with fee), showing cost and delivery estimate.
4. Review everything on a confirmation screen: amount, fees, total, recipient name, masked account, delivery date, irrevocability and scam warnings.
5. Authenticate if required (step-up MFA).
6. Submit with an idempotency key, disabling double submission.
7. Confirm with a reference number, status, and next steps; offer a printable or downloadable receipt.
8. Track status updates in activity history, with notifications.

Idempotency in Practice

function useSubmitPayment() {
  const keyRef = useRef<string | null>(null);
  return useMutation({
    mutationFn: async (payment: PaymentRequest) => {
      keyRef.current ??= crypto.randomUUID();     // one key per logical submission
      const { data } = await api.post('/payments', payment, {
        headers: { 'Idempotency-Key': keyRef.current },
        timeout: 30_000,
      });
      return data;
    },
    onSuccess: () => { keyRef.current = null; },
  });
}

If the request times out, the client does not know whether the payment was created. Retrying with the same key lets the server return the original result instead of creating a second payment. Generate a new key only when the user starts a genuinely new payment. Persist the key with the draft if the flow can survive a page reload.

Payment Status Model

type PaymentStatus =
  | 'draft'
  | 'pending_approval'      // awaiting second approver (business accounts)
  | 'scheduled'             // future-dated
  | 'processing'            // submitted to the rail
  | 'sent'                  // accepted by the network (instant) or file transmitted (ACH)
  | 'completed'             // settled / credited
  | 'returned'              // ACH return after completion
  | 'failed'                // rejected; include reason code
  | 'cancelled';

Map backend statuses to user-friendly language and never overstate certainty: an ACH credit “sent” today may still be returned. Show timestamps for each transition and the expected next step.

Maker-Checker (Dual Control)

Business banking often requires that one user creates a payment and a different user approves it, with approval limits per user and role. The UI needs approval queues, clear indicators of who created and who must approve, the ability to reject with a reason, and audit trails. The backend enforces segregation of duties; the UI must never offer an approve button to the payment’s creator.

Cutoff Times and Business Days

Compute expected dates on the server using the bank’s holiday calendar and rail-specific cutoffs, and return them to the UI, rather than duplicating calendar logic in the browser. The frontend displays the result with explicit time zone labels and updates the estimate if the user lingers past a cutoff (or re-validates on submit).

Compliance and Controls That Shape the UI

Regulation or control	What it is	Frontend impact
KYC / CIP	Know Your Customer and Customer Identification Program	Onboarding forms, document capture, identity verification SDKs
AML / BSA	Anti-money laundering, Bank Secrecy Act	Payment holds and reviews; “under review” statuses
OFAC sanctions screening	Screening against sanctions lists	Delays or blocks; must not disclose screening details to users
Regulation E	Consumer electronic fund transfer protections (error resolution, disclosures)	Disclosures, dispute flows, receipts
Remittance Rule (Reg E Subpart B)	Disclosures for consumer international transfers	Fees, FX rate, delivery date, cancellation rights shown before and after
Regulation CC	Funds availability for deposits	Showing holds and availability dates on mobile check deposit
UCC Article 4A	Law governing commercial funds transfers	Security procedures for wires (authentication, callbacks)
Nacha rules	ACH operating rules	Authorization language, account validation, returns
PCI DSS v4.0	Payment card data security standard	Hosted fields/iframes; script inventory and integrity monitoring on payment pages
GLBA / privacy laws	Protection of consumer financial data	Data minimization, masking, consent
SOX / audit	Financial controls for public companies	Audit trails, segregation of duties in admin tools

PCI DSS v4.0 requirements 6.4.3 and 11.6.1 (effective March 2025) specifically affect frontends: organizations must inventory and authorize every script on payment pages, verify their integrity, and detect unauthorized changes to payment page content and HTTP headers, defenses against Magecart-style skimming attacks that inject malicious JavaScript to steal card data. CSP, SRI, and hosted payment fields are the main tools.

Fraud Prevention Patterns in the UI

• Confirmation of payee name when adding recipients, warning on mismatches.
• Cooling-off periods or lower limits for newly added payees.
• Contextual scam warnings (“Has someone asked you to move money to keep it safe? This is a scam.”) on high-risk transfers.
• Out-of-band verification (callbacks) for changed wire instructions.
• Device and behavioral signals collected by SDKs and sent with sensitive requests.
• Notifications to the customer for every payment, new payee, and profile change.
• Clear, accessible ways to report fraud.

Ledger and Data Concepts

Frontend engineers benefit from understanding the backend’s model:

• Double-entry accounting: every transaction has equal debits and credits across accounts; balances are derived from ledger entries.
• Immutability: posted transactions are never edited; corrections are new entries (reversals).
• Pending versus posted: card authorizations and ACH entries appear as pending before posting; amounts can change (a restaurant tip) or drop off.
• Running balances in transaction history must be computed by the backend in posting order; client-side computation is error-prone with pending items and pagination.

Interview Questions and Answers

Q1. Explain the difference between ACH, RTP, and wire transfers.

ACH is a batch system processing credits and debits in settlement windows, settling in one or two business days (or same day with Same Day ACH), low cost, and returnable for reasons like insufficient funds or unauthorized debits. RTP (and FedNow) are 24×7 instant credit-push systems with immediate, irrevocable settlement and rich ISO 20022 data. Wires are high-value, individually settled payments via Fedwire (real-time gross settlement on business days) or SWIFT for international, also irrevocable, with higher fees and strong fraud controls.

Q2. Why must money never be stored as a floating-point number?

Binary floating-point cannot represent most decimal fractions exactly, causing rounding errors in arithmetic, comparisons, and display. Use integer minor units, decimal strings in APIs, and a decimal library for arithmetic, with explicit currency and rounding rules agreed with the backend.

Q3. How do you prevent a user from being charged twice when they double-click “Pay” or the network times out?

Disable the submit control while the request is in flight, generate an idempotency key once per logical payment and send it with the request and any retries, and rely on the server to return the original result for duplicate keys. On timeout, query the payment status or retry with the same key rather than creating a new payment.

Q4. What does “irrevocable” mean for RTP, and how does it affect UI design?

Once an instant payment is accepted, the sender cannot cancel or reverse it; only the recipient can voluntarily return funds. The UI therefore needs a clear review step, recipient name confirmation, explicit warnings, scam education, and step-up authentication for risky payments.

Q5. What is an ACH return, and how should the UI handle it?

A return sends an ACH entry back to the originating bank because it could not be posted or was disputed, with a reason code such as R01 (insufficient funds) or R10 (unauthorized). The UI should update the payment status to returned with a plain-language reason, adjust balances as the backend reports, notify the user, and prompt corrective action, such as updating account details for R03 or R04.

Q6. What are cutoff times, and where should business-day logic live?

Deadlines after which a payment is processed in the next window or business day. Business-day and cutoff calculations should live on the server, using the payment system’s holiday calendar and the bank’s time zone; the frontend displays the server-calculated delivery date with explicit time zones and re-validates at submission.

Q7. How would you design a payment status display?

Use a clear status model (scheduled, processing, sent, completed, returned, failed, cancelled), show plain-language explanations and timestamps for each step, include reference numbers, avoid overstating finality (an ACH credit can still be returned), and provide next actions such as cancelling a scheduled payment or contacting support. Update in real time where the backend provides events.

Q8. What is maker-checker?

A dual-control process where one user initiates a payment and another authorized user approves it before release, with role-based limits. It reduces fraud and errors and is common in commercial banking. The backend enforces it; the UI provides approval queues and audit information and never lets a user approve their own payment.

Q9. How do you validate a US routing number on the client?

Check that it is nine digits and passes the ABA checksum: 3 times the sum of digits 1, 4, 7, plus 7 times the sum of digits 2, 5, 8, plus the sum of digits 3, 6, 9 must be divisible by 10. Then verify existence and eligibility for the chosen rail via a server-side lookup. Client validation improves UX but does not replace server checks.

Q10. What is ISO 20022, and why does it matter?

An international standard for financial messaging using structured XML data. RTP, FedNow, Fedwire (since 2025), and SWIFT cross-border payments use it. Richer, structured data enables better remittance information, sanctions screening, and reconciliation, and frontends may need to collect structured fields such as structured addresses and purpose codes.

Q11. How does PCI DSS affect frontend development?

It governs handling of cardholder data. Using the processor’s hosted fields or iframes keeps card data off your systems and reduces scope. PCI DSS v4.0 requirements 6.4.3 and 11.6.1 require inventorying, authorizing, and integrity-checking scripts on payment pages and detecting unauthorized changes, which pushes teams toward strict CSP, SRI, minimal third-party scripts, and monitoring.

Q12. A customer wants to send $50,000 for a house closing tomorrow. What rail and UX would you recommend?

A domestic wire, or an instant payment if the receiving bank supports it and limits allow, because the funds must arrive with finality on a deadline. The UX should show cutoff times, fees, and delivery expectations, require strong authentication, warn about real estate wire fraud and advise verifying instructions by calling a known number, and provide a tracking reference.

Q13. How would you display available versus current balance?

Show the available balance prominently for decisions like transfers, with a clear label, and provide the current (ledger) balance and an explanation of the difference (pending transactions and holds) on demand. Pending items should be visually distinct in transaction history.

Q14. How do you handle a payment request that times out?

Do not assume failure. Show a “we’re confirming your payment” state, query the payment status using the idempotency key or reference, or retry the submission with the same idempotency key so the server returns the existing result. Only allow a new submission after confirming the first did not succeed.

Q15. How do you calculate and display fees accurately?

Get fees from the backend (via a quote endpoint) rather than duplicating fee logic in the frontend, display them before confirmation along with totals, and include them on receipts. If a quote can expire (for FX rates), show its validity and re-quote on expiry.

Q16. What is authorized push payment fraud, and how can the UI help prevent it?

Fraud where criminals manipulate customers into sending payments themselves, for example by impersonating the bank or a supplier. The UI can help with confirmation of payee name checks, contextual warnings based on risk signals, friction such as cooling-off periods for new payees, clear statements that the bank will never ask customers to move money, and easy fraud reporting.

Q17. Why is allocation tricky when splitting money?

Dividing $100.00 three ways produces $33.333…, which cannot be represented in cents. Naive rounding loses or creates a cent. Allocation algorithms distribute the remainder (for example $33.34, $33.33, $33.33) so the parts sum exactly to the total, as dinero.js allocate does.

Q18. What regulations require specific disclosures in a payment UI?

Regulation E requires disclosures and error-resolution rights for consumer electronic transfers, and its Remittance Rule requires pre-payment disclosures of fees, exchange rate, and amount received and a receipt with delivery date and cancellation rights for international consumer transfers. Nacha rules require proper authorization language for debits. Truth in Savings and other rules govern account disclosures.

Q19. What is OFAC screening, and how does it show up in the UI?

Screening of parties and payments against US sanctions lists maintained by the Office of Foreign Assets Control. Payments may be held for review, so the UI should show a neutral “under review” status with expected timing, without revealing screening details, and support teams need tools to manage cases.

Q20. How would you design a recurring payments feature?

Collect frequency, start date, end condition (date, number of payments, or until cancelled), amount, and recipient; show the next several scheduled dates computed by the backend with business-day adjustments; allow skip, edit, and cancel with clear effective dates; notify before and after each payment; and handle failures with clear retry or stop behavior.

Key Takeaways

• ACH is batch, cheap, and returnable; RTP and FedNow are instant and irrevocable; wires are high-value, final, and fraud-targeted.
• Represent money with integer minor units or decimal strings and libraries; never floats.
• Use idempotency keys, explicit status models, and honest delivery estimates in payment flows.
• Business-day, cutoff, fee, and limit logic belongs on the server; the UI communicates it clearly.
• Regulations (Reg E, Nacha, UCC 4A, PCI DSS) and fraud controls shape payment UX.

---

← Part 13: Git and CI/CD Pipelines · All chapters · Part 15: Java and Spring Boot for Frontend Engineers →

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Comment *

Name *

Email *

Website

Δ