Candescent — BFSI Domain Fluency (covers the JD's "BFSI EXPERIENCE" pointer)¶

This file makes you banking-fluent so you can frame every automation answer in banking terms and raise banking-specific test concerns before the interviewer asks. You don't need banking employment to sound credible — you need the vocabulary, the concerns, and the worked scenarios in this file.

0. How to use this file¶

Three passes: 1. Read for vocabulary (§2) until ACH / wire / settlement / hold / ledger-vs-available come out of your mouth naturally. 2. Memorize the 8 test concerns (§3) — these are what separates a banking tester from a generic one. Drop at least 3 of them unprompted in any design answer. 3. Rehearse the scenarios & Q&A (§4, §7) out loud.

Golden rule for the interview: when given any automation/design question, re-skin it in banking terms. "Test a checkout" → "test a fund transfer." "Validate a form" → "validate KYC onboarding." That re-skin alone signals domain fit.

1. What Candescent does, and what it means for a tester¶

Candescent = the former NCR Voyix Digital Banking business. It sells digital banking + ATM/self-service software to US banks and credit unions (CUs). It does not hold your money — it's the software platform that the financial institution (FI) puts in front of its members/customers, sitting on top of the FI's core banking system (the system of record for accounts and balances).

The apps under test (what you'd be automating)¶

App / surface	What it does	Headline test concerns
Retail online banking (web)	Balances, transaction history, transfers, statements, alerts	Money math, balance accuracy, entitlements (see only your accounts), session security
Mobile banking app (iOS/Android)	Same as web + mobile deposit (check capture), biometric login, push	Biometric/MFA, offline/poor-network, device fragmentation, push notifications
Account opening / onboarding	New customer/member signup, KYC/CIP identity checks, funding the first deposit	Identity-verification happy + reject paths, document upload, abandon/resume
Payments & transfers	Internal transfers, ACH, wire, RTP/real-time, P2P (Zelle-style)	Idempotency/double-debit, limits, real-time status, insufficient-funds
Bill pay	Pay billers/payees, scheduled & recurring payments, eBills	New-payee setup, scheduling, date math, cancel-before-cutoff
Card management	View/activate cards, lock/unlock, set travel notices, dispute a charge	Card state machine, PAN masking, dispute/chargeback flow
ATM / branch self-service	Withdrawals, deposits, balance inquiry at the machine	Cash dispense vs ledger reconciliation, hardware/network failure mid-transaction

The mental model: the app you test is a thin, friendly face on top of a core that owns the truth. Most banking bugs live in the seam between them — stale balances, double-posts, money shown that the core hasn't actually moved yet. So a lot of your testing is "does the UI agree with the system of record, always, even under failure?"

Bank vs credit union: functionally near-identical for testing. A bank is a for-profit institution with customers; a credit union is a not-for-profit member-owned cooperative with members (note the word — say "member" when discussing a CU). Candescent serves both, so multi-tenant / white-label configurability is a real concern (the same platform is branded per-FI).

2. BFSI vocabulary cheat-sheet (plain-English)¶

Use these naturally. The plain-English gloss is what proves you understand it, not just memorized it.

Payments & money movement¶

Term	Plain English	Tester's note
ACH (Automated Clearing House)	US batch electronic transfer (payroll, bill pay, most "bank transfers"). Cheap, not instant — settles in batches, often next-day.	Test the pending → settled state change; test the cutoff time (after cutoff = next business day).
Wire transfer	High-value, same-day, irreversible push of funds, settled individually (not batched).	Irreversibility is the test point — there's no "undo." Confirm step + limits matter.
RTP / real-time payments	Instant, 24/7, irreversible US rails (TCH RTP, FedNow).	Status is immediate and final — test sub-second status, idempotency hard.
NEFT / IMPS / UPI	India's rails (NEFT = batch like ACH; IMPS/UPI = instant like RTP).	US context here — mention these only to show breadth, then say "the US equivalents are ACH and RTP/FedNow."
Wire vs ACH	Wire = instant, irreversible, expensive, individual. ACH = slow, reversible-ish, cheap, batched.	Knowing the difference is a classic banking-domain question.
Debit / credit	Debit = money out of an account; credit = money in. (Accounting sense can flip — for a test answer use the everyday sense.)	A transfer is a debit on the source and a credit on the destination.
Settlement vs clearing	Clearing = exchanging the payment instructions / netting who-owes-whom. Settlement = the actual money changing hands. Clearing first, settlement after.	The window between them is where "pending" balances live — prime test territory.
Reconciliation	Proving two independent records agree (e.g., ATM cash dispensed vs ledger postings; our app's view vs the core).	A whole class of banking tests = reconciliation assertions.
Interchange	The fee the merchant's bank pays the cardholder's bank on a card transaction.	Mostly relevant to fee/statement calculations.

Balances, ledger & posting¶

Term	Plain English	Tester's note
Core banking system	The FI's system of record for accounts, balances, and the ledger. Candescent's apps sit on top of it.	You'll often mock/stub the core in lower environments.
Ledger (posted) balance	The "official" balance of settled transactions.
Available balance	What you can actually spend now = ledger balance − holds + cleared credits.	Available ≠ ledger is the #1 thing to test. A pending card auth lowers available but not ledger.
Hold / authorization	A temporary reservation of funds (e.g., gas station pre-auth, hotel hold) that reduces available balance until it settles or expires.	Test hold placed → settles to a different/lower amount → hold released.
Ledger posting	Writing a transaction line into the ledger (the durable, ordered record).	Posting must be ordered, atomic, and immutable.
Statement cycle	The recurring period (usually monthly) over which transactions are summarized into a statement.	Month-end = a load + correctness hotspot; test boundary dates.
Overdraft	Spending past your balance into negative, by arrangement (the bank covers it, usually for a fee).	Test the negative-balance path and fee application.
NSF (Non-Sufficient Funds)	Transaction declined because there isn't enough money (and no overdraft cover) → often an NSF fee.	Test the decline path: no money moves, correct fee, correct message.
Idempotency	Doing the same operation twice has the same effect as doing it once.	Critical for payments — a retried transfer must not debit twice. (See §3.)

Identity, security & compliance¶

Term	Plain English	Tester's note
KYC (Know Your Customer)	The legal duty to verify who a customer is before onboarding.	Drives the onboarding happy/reject paths.
CIP (Customer Identification Program)	The specific identity data you must collect/verify under KYC (name, DOB, address, SSN/ID).	The data checklist for an onboarding test.
AML (Anti-Money Laundering)	Rules/monitoring to stop money laundering (suspicious-activity detection, thresholds).	Test threshold-triggered flags / blocked transactions.
BSA (Bank Secrecy Act)	The US law underpinning AML reporting (e.g., large-cash reports).	The "why" behind AML controls.
NACHA	The body that governs the ACH network and its rules/file format.	ACH file-format & return-code validation references NACHA.
PAN (Primary Account Number)	The 16-digit card number. Sensitive — must be masked/encrypted.	Assert it's masked everywhere (e.g., `** ** 1234`) and never in logs.
CVV / CVC	The 3-digit card security code. Never stored post-authorization (PCI rule).	Assert it's never persisted or logged.
Tokenization	Replacing a PAN with a non-sensitive token so the real number isn't stored/handled.	Verify the token, not the PAN, flows through downstream systems.
3-D Secure	The "Verified by Visa / Mastercard SecureCode" extra auth step on online card payments.	An extra MFA-style step in card flows.
OTP / MFA	One-time passcode / multi-factor auth (something you know + have + are).	Test OTP expiry, reuse, wrong-code lockout, resend.
SSO	Single sign-on across multiple apps with one login.	Test the session/token propagation and logout-everywhere.
PII	Personally Identifiable Information (SSN, DOB, address, account #).	Must never appear in lower-env test data or logs.
PCI-DSS	The card-data security standard (Payment Card Industry).	Shapes masking, encryption, log-hygiene test evidence.
GLBA	Gramm-Leach-Bliley Act — US law requiring FIs to protect customer financial privacy.	The "why" behind PII protection in banking specifically.
SOX	Sarbanes-Oxley — financial-reporting controls/auditability for public companies.	Drives audit-trail & change-control test evidence.

Customers & instructions¶

Term	Plain English	Tester's note
Beneficiary / payee	The person/biller you send money to.	New-payee setup is a heavily-tested onboarding-within-the-app flow.
Standing instruction	A pre-set recurring/automatic payment ("pay £X to Y every month").	Test schedule math, the next run, edit/cancel, and skip-on-holiday.
Dispute / chargeback	Customer contests a charge; bank claws it back from the merchant.	A state machine: raised → investigating → resolved/reversed.
Credit union vs bank	CU = member-owned, not-for-profit; bank = for-profit, customers.	Say "member" for CUs. Same testing, different branding/config.

3. Banking-specific TEST CONCERNS to raise unprompted¶

These eight are your differentiators. For each: the concern, why it's special in banking, and an example test. Memorize the bolded one-liners.

3.1 Money math — "you never store money in a float."¶

Why: floating-point (float/double) can't represent decimal cents exactly — 0.1 + 0.2 = 0.30000000000000004. Over millions of transactions those errors compound into real, auditable money loss. Banking uses fixed-precision decimals (BigDecimal in Java, decimal in C#, never binary floats).
Test it:
Transfer 0.10 + 0.20, assert balance is exactly 0.30, not 0.30000….
Rounding: when splitting/calculating interest, assert banker's rounding (round-half-to-even: 2.5 → 2, 3.5 → 4) is used consistently — it removes the upward bias of always-round-half-up.
Currency formatting: 1234.5 displays as $1,234.50 (two decimals, thousands separator, locale-correct).
Boundaries: zero ($0.00 transfer rejected/handled), negative (overdraft), very large amounts (no overflow), and the smallest unit (1 cent).

3.2 Idempotency & double-spend — "a retried transfer must not debit twice."¶

Why: networks drop responses. The client/app retries. Without protection, the same transfer executes twice → the customer is debited twice. This is the single most important payment-integrity property.
How it's solved: each payment request carries an idempotency key (a unique ID). The server records the key; a second request with the same key returns the original result without re-executing.
Test it: submit a transfer, capture the request, replay the identical request (same idempotency key). Assert: exactly one debit, one ledger entry, and the second call returns the same transaction ID (not a new one). Then test a different key → genuinely processes again. Also test concurrent duplicate submits (double-click, two tabs).

3.3 Real-time accuracy & concurrency — "the balance the customer sees must match the truth, even under a race."¶

Why: balances update from many sources at once (a card auth, an incoming ACH, a transfer). Two operations on the same account can race and corrupt the balance or let you overdraw.
Test it:
Real-time status: for an RTP/instant transfer, assert status flips to final within the SLA and the destination balance reflects it immediately; for ACH, assert it sits pending then settles later.
Race / concurrency: fire two simultaneous transfers from an account with only enough for one. Assert exactly one succeeds, the other gets a clean insufficient-funds decline, and the final balance is never negative or double-debited. (Classic lost-update / overdraw bug.)
Stale read: make a transfer, immediately re-query the balance via a different channel (web vs mobile vs API) — all must agree.

3.4 Security, PII & entitlements — (tie this to your VAPT background — it's your edge)¶

Why: banking is the highest-value attack target and the most regulated. Your security/VAPT experience is a genuine differentiator here — lead with it.
Test it:
Authorization / entitlements (broken object-level auth): logged in as user A, change the account ID in the request to user B's account. Assert a 403/denied, not user B's data. This is the #1 banking API vuln (IDOR/BOLA) and exactly the kind of thing VAPT trains you to find.
PAN/PII masking: assert card numbers show as **** 1234 in UI and are masked/absent in logs, error messages, and API responses. CVV never stored.
Encryption: in transit (TLS, no plaintext on the wire) and at rest (sensitive fields encrypted in DB).
Session: idle session timeout logs the user out; token invalidated on logout; no session-fixation; concurrent-session policy.
MFA/OTP: expiry, single-use, wrong-code lockout/throttle, resend rate-limit.
OWASP for banking: injection, broken auth, IDOR/BOLA, mass assignment, rate-limiting on money-moving endpoints.

3.5 Data integrity & audit trail — "every money movement is logged immutably and reconciles."¶

Why: regulators and the FI must be able to reconstruct exactly what happened, when, and by whom — forever. Audit logs are append-only/immutable (you can never edit or delete a posted entry; you post a correcting reversal instead).
Test it:
After any transaction, assert an audit record exists with who/what/when/amount/before-after balance.
Assert you cannot mutate a posted ledger entry — a correction creates a new reversing entry, preserving history.
Reconciliation test: sum of all debits/credits on an account == change in balance; app's transaction list == core's ledger.

3.6 Compliance & regulation shapes your test evidence — "in banking, the test isn't done until it's traceable."¶

Why: SOX, PCI-DSS, GLBA, BSA/AML mean tests aren't just pass/fail — they're audit evidence. You need traceability (requirement → test → result), retained run artifacts, formal sign-off, and "living documentation" (BDD/Gherkin specs that double as readable, current requirements).
Test it / process:
Maintain a requirement-to-test traceability matrix so an auditor can see every control is covered.
Keep immutable run artifacts (reports, screenshots, logs) retained per policy.
Use Gherkin/BDD so business + compliance can read the specs as living documentation.
Gate releases with documented sign-off; tie tests to change-control tickets (SOX change management).

3.7 Accessibility & localization — "banks get sued over WCAG; it's not optional."¶

Why: under the ADA, US banks are routinely sued when their sites fail WCAG (e.g., screen-reader-inaccessible). Accessibility is a legal/financial risk, not a nice-to-have.
Test it: automated axe/Lighthouse scans in CI for WCAG 2.1 AA (contrast, labels, keyboard nav, focus order, ARIA), plus manual screen-reader passes on the critical money flows. Localization: currency/number/date formats per locale, RTL where relevant, translated strings without truncation, and locale-correct rounding.

3.8 Non-functional: performance, resiliency, DR — "month-end is a load event; mid-transaction failure must not lose money."¶

Why: banking has predictable load spikes (payday, month-end statements, tax day) and a zero-tolerance for inconsistent state after a crash.
Test it:
Performance: statement generation and month-end batch under load; login storm at 9am; payment throughput.
Resiliency/failover: kill the core connection mid-transfer — assert no partial/double debit (transaction rolls back or replays idempotently), graceful error to the user.
DR: failover to standby, recovery-time/recovery-point objectives (RTO/RPO), data consistency after restore.

4. Worked end-to-end banking test scenarios¶

Each is written as you'd talk it through on a whiteboard: setup, steps, key assertions (bold = the banking-specific ones).

Scenario A — Fund transfer between own accounts (+ insufficient funds + daily limit)¶

Setup: User with Checking ($500.00) and Savings ($0.00); a configured daily transfer limit of $1,000.00.

Happy path 1. Login (MFA). Navigate to Transfer. Select From=Checking, To=Savings, Amount=$200.00. Confirm. 2. Assert: success message + transaction reference returned. 3. Assert Checking ledger & available = $300.00 exactly; Savings = $200.00 exactly (no float drift). 4. Assert two ledger entries: a debit on Checking and a matching credit on Savings, same reference (double-entry). 5. Assert an immutable audit record (who/when/amount/before-after).

Insufficient funds 6. Transfer $5,000.00 from Checking ($300.00). Assert: clean NSF/insufficient-funds decline, friendly message, no money moves, no ledger entry, balances unchanged, and (per config) an NSF fee or none.

Daily limit 7. Transfer $1,001.00 (over the $1,000 daily limit). Assert: blocked with a limit-exceeded message, no debit. 8. Boundary: a $1,000.00 transfer (exactly at limit) succeeds; a second transfer that would push the cumulative day total over the limit is blocked (BVA on the running daily total, not just the single amount).

Idempotency/concurrency 9. Double-click "Confirm" / replay the request → exactly one debit (§3.2). 10. Concurrent transfers draining the account → exactly one succeeds, no negative balance (§3.3).

Scenario B — Bill pay to a new payee¶

Setup: Logged-in user, no existing payee "City Electric". 1. Bill Pay → Add Payee → enter name, account number, address → save. 2. Assert payee saved; assert the payee account number is masked in the UI list and validated (length/checksum if applicable). 3. Schedule a payment: Amount=$120.00, Date=today. Submit. 4. Assert the send date respects the cutoff — if past the daily cutoff, the effective/processing date rolls to the next business day (and skips weekends/bank holidays). 5. Assert payment shows pending (ACH-style), available balance reduced by $120.00, ledger not yet posted. 6. Cancel before cutoff: cancel the pending payment → assert it's cancelled and the held funds are released. 7. Recurring: set "every month" → assert the next scheduled run date is computed correctly (month-end edge: Jan 31 → Feb 28/29). 8. Negative: duplicate payee, invalid account number, $0.00 payment → all rejected cleanly.

Enter valid username/password → assert OTP/MFA challenge appears.
OTP correctness: wrong code → error + attempt counter; after N wrong → lockout/throttle. Expired OTP → rejected. Reused (already-consumed) OTP → rejected. Resend is rate-limited.
Valid OTP → logged in; assert a session token is issued.
Session timeout: idle past the timeout → next action forces re-auth; assert the old token is invalidated server-side (replaying it = 401), not just a client redirect.
Logout → token invalidated everywhere; back-button doesn't show authenticated pages.
Entitlement check: while logged in as A, call an account endpoint with B's account ID → 403, not B's data (§3.4).

Scenario D — Account opening / KYC (happy + rejected)¶

Happy path 1. Start application → enter CIP data (name, DOB, address, SSN/ID), upload ID document. 2. Submit → KYC/identity check passes (mock the identity provider to return "verified"). 3. Assert account is created with a valid account number, initial status, and zero/funded opening balance. 4. Fund the first deposit (e.g., ACH pull from external account) → assert pending → settled. 5. Assert an audit trail of the onboarding decision (verified, by which check, when).

Rejected path 6. Submit data that the mocked identity provider returns "not verified / watchlist hit". 7. Assert: account is not created (or held in manual-review state), a clear message to the user, no usable account/funds, and a logged compliance reason. 8. Edge: abandon mid-application then resume; expired/blurry document; underage DOB (BVA on the 18-year boundary); duplicate SSN.

Scenario E — ATM withdrawal reconciliation against the ledger¶

Setup: Account available balance $300.00; ATM dispenses cash; the core holds the ledger. 1. Request $100.00 withdrawal. Assert: available balance immediately reduced to $200.00 (hold/auth), cash dispensed. 2. Reconciliation assertion: the cash dispensed ($100) == the ledger debit ($100) — no mismatch. Sum of all ATM dispenses for the session == sum of corresponding ledger postings. 3. Failure mid-transaction (the classic ATM test): simulate network/core failure after the debit request but before cash dispenses. Assert the system either (a) doesn't debit, or (b) debits then auto-reverses when no cash was dispensed — the customer is never debited for cash they didn't receive. 4. Over-limit / NSF: request $400.00 (> available) → declined, no dispense, no debit. 5. Boundary: request a non-dispensable amount (not a multiple of the smallest note) → rejected with the right message.

5. Test data & environment strategy in banking¶

This is a topic interviewers love because it exposes whether you understand compliance constraints on data.

Test data¶

No real PII in lower environments — ever. GLBA/PCI make using real customer SSNs, PANs, names, or balances in dev/QA a compliance violation. Say this explicitly; it shows domain maturity.
Synthetic data: generate fake-but-valid accounts, customers, and card numbers. Use test PANs (the official network test card numbers), Luhn-valid fake numbers, fake SSNs in reserved ranges, and seeded balances.
Masked / tokenized prod data: if production-like data is needed for realism, it must be masked, anonymized, or tokenized first (irreversibly de-identified), never raw copied.
Deterministic seeding: seed accounts to known balances before each test (e.g., Checking=$500) so money-math assertions are exact and repeatable. Tear down / reset between runs to keep idempotency tests clean.
Data privacy in artifacts: screenshots/logs/reports are also evidence — assert they don't leak PII/PAN.

Environment strategy¶

Mock the core banking system in lower envs. The real core is expensive, shared, and slow; stub it so QA controls balances, holds, and responses deterministically. WireMock / service virtualization for the core's REST/SOAP APIs.
Stub the external rails / third parties: ACH operator, card networks, the identity/KYC provider, the OTP/SMS gateway, the wire system. Stubbing lets you force the hard paths: ACH return codes, KYC "watchlist hit", card decline codes, timeouts, and partial failures you can't trigger against a live network.
Contract tests against the real core/rails periodically so your mocks don't drift from reality.
Environment parity & config: because the platform is white-labeled per-FI, test that per-FI config (branding, limits, enabled features) is honored — same code, different tenant.
Cutoff/clock control: be able to control "business date" and cutoff times so you can test next-business-day rollover and statement-cycle boundaries without waiting.

6. How to talk about banking experience you don't formally have (honesty note)¶

Be truthful — never claim banking employment you don't have. Instead, map your real, transferable work onto banking concerns. Interviewers respect this far more than a fabricated story, and your skills genuinely transfer.

Your real experience	Honest banking framing
RestAssured API automation framework	"I've built API automation that chains requests, validates schemas, status codes, and end-to-end flows — exactly what payment/transfer APIs need, including idempotency replay and entitlement/authorization checks."
Security / VAPT background	"Security is where I'm strongest, and it's central to banking. I naturally test for IDOR/BOLA (one user reaching another's accounts), PII/PAN leakage in logs, session handling, and OWASP issues — the highest-risk banking defects."
Data validation work	"I've done rigorous data-integrity validation, which maps directly to money-math precision, double-entry/ledger reconciliation, and audit-trail assertions."
E-commerce checkout / payments	"My e-commerce checkout/payments work covers the same concerns banking cares about: decimal money math, double-charge prevention, declined-payment paths, and PCI card-data handling — I'd extend those into ACH/wire/RTP rails."

Scripted honest line for the interview:

"I haven't worked inside a bank, but a lot of my work maps directly onto banking concerns. My e-commerce payments and RestAssured API work already deal with money precision, double-charge prevention, and declined paths, and my VAPT background means I instinctively test for the high-risk banking issues — authorization gaps where one user could reach another's accounts, and PII or card-number leakage. I've done the domain homework on ACH vs wire vs real-time payments, ledger-vs-available balances, and KYC, so I can frame my testing in banking terms from day one."

Practice that until it's natural. It's confident, specific, and 100% true.

7. Likely BFSI domain interview Q&A (model answers)¶

Q1. What's special about testing money?

Money is exact and irreversible, so the bar is higher than normal apps. First, precision — never floats; use fixed-decimal types like BigDecimal, and I assert balances to the exact cent so float drift (0.1+0.2) can't hide. Second, rounding must be consistent and usually banker's rounding to avoid bias. Third, every movement is double-entry and auditable — a debit has a matching credit, and there's an immutable audit record. Fourth, boundaries — zero, negative/overdraft, and very large amounts. And formatting/locale for display.

Q2. How would you test a fund transfer?

I'd cover happy path with exact balance assertions on both accounts and matching debit/credit ledger entries; insufficient funds (clean decline, no money moves); daily/per-transaction limits including BVA on the cumulative daily total; idempotency (replay the request → one debit only); concurrency (two simultaneous transfers draining the account → exactly one succeeds, never negative); real-time vs pending status depending on the rail (RTP instant vs ACH pending→settled); and an audit-trail assertion. Plus security: that I can't transfer from an account I don't own.

Q3. How do you test for double-debit / double-spend?

The mechanism is an idempotency key on the payment request. I submit a transfer, then replay the identical request with the same key and assert exactly one debit, one ledger entry, and that the second call returns the original transaction ID rather than creating a new one. I also test the real-world triggers: double-clicking confirm, two browser tabs, and a client retry after a dropped response. And a different key must process as a genuine new transfer.

Q4. What's the difference between ledger balance and available balance, and how do you test it?

Ledger (posted) balance is settled transactions only; available balance is what you can spend now = ledger minus holds plus cleared credits. The classic test: place a card authorization/hold — assert available drops but ledger doesn't; then settle it (often a different amount, like a tip) — assert ledger updates and the hold releases; or let the hold expire — assert available restores. Confusing the two is a common real bug.

Q5. How would you test real-time balance updates?

Depends on the rail. For RTP/instant, after a transfer I assert the status goes final and the destination balance reflects it within the SLA, immediately. For ACH, I assert it sits pending (available reduced, ledger not yet) and settles later. I test cross-channel consistency — query the balance via web, mobile, and API and assert they all agree — and concurrency so a race can't show or allow a wrong balance.

Q6. ACH vs wire vs RTP — what's the difference and why does it matter for testing?

ACH is cheap, batched, US, not instant (often next-day), and somewhat reversible — so I test pending→settled, cutoff-time rollover, and return codes. Wire is same-day, individually settled, and irreversible — so I test the confirmation step, limits, and that there's genuinely no undo. RTP/FedNow is instant, 24/7, and final — so I test sub-second final status and tighter idempotency. The reversibility and timing differences change exactly what I assert.

Q7. How do you ensure PII isn't leaked in test environments?

Two rules. One, no real PII in lower envs — that's a GLBA/PCI violation; I use synthetic data (test PANs, Luhn-valid fakes, reserved-range SSNs, seeded balances) or masked/tokenized data if production-like realism is required. Two, I test for leakage: assert PAN is masked in UI/API/error messages, CVV is never stored, and that logs, screenshots, and reports don't contain PII either — the artifacts are evidence too.

Q8. A user reports they can see someone else's account. How would you have caught that in testing?

That's a broken object-level authorization / IDOR bug, and it's the top banking API vuln. My standard test: authenticated as user A, take an endpoint like /accounts/{id} and substitute B's account ID. It must return 403/denied, never B's data. I do this for every object-scoped endpoint — accounts, transactions, statements, cards — and at the API layer, not just the UI, since the UI just hides the link. My VAPT background makes this reflexive.

Q9. How does compliance/regulation change how you test?

In banking, a test isn't done until it's traceable evidence. SOX, PCI, GLBA, and BSA/AML mean I keep a requirement-to-test traceability matrix so an auditor can see every control is covered, I retain run artifacts (reports/logs/screenshots) per policy, I tie tests to change-control for SOX, and I write specs in Gherkin/BDD as living documentation business and compliance can read. Tests become audit artifacts, not just a pass/fail gate.

Q10. How would you mock the core banking system, and why?

The real core is shared, slow, and expensive, and I can't easily force its edge cases. So in lower envs I virtualize it — WireMock/service virtualization over its REST/SOAP APIs — so QA deterministically controls balances, holds, and responses, and can force the hard paths: ACH returns, declines, timeouts, partial failures. I keep contract tests against the real core periodically so the mocks don't drift. I stub the external rails too — card network, KYC provider, OTP gateway.

Q11. How would you test an ATM withdrawal?

Happy path: available balance reduces and cash dispensed equals the ledger debit — a reconciliation assertion. Then the critical failure case: a network/core failure after the debit but before cash dispenses — the customer must never be debited for cash they didn't get, so I assert either no debit or an auto-reversal. Plus NSF/over-limit declines (no dispense, no debit) and invalid-amount boundaries (non-dispensable denominations).

Q12. How would you test account opening / KYC?

Happy path: submit valid CIP data + ID doc, mock the identity provider to return "verified", assert the account is created with a valid number and correct opening balance, and that the onboarding decision is audited. Reject path: mock a "not verified / watchlist hit" → assert no usable account or funds, a clear user message, and a logged compliance reason (or manual-review hold). Edges: 18-year DOB boundary (BVA), duplicate SSN, expired/blurry document, and abandon-then-resume.

Q13. How do you test a recurring/scheduled payment (standing instruction)?

I assert the next-run date math is correct, especially the nasty edges: monthly on the 31st rolling to Feb 28/29, and weekend/bank-holiday rollover to the next business day. I test edit and cancel (cancel before cutoff releases held funds), the cutoff-time boundary, and that exactly one payment fires per period — no skips, no duplicates. And the failure path: if a run hits insufficient funds, the right retry/notify behavior.

Q14. What non-functional concerns matter most in banking, and how do you test them?

Performance around predictable spikes — month-end statement generation, payday login storms, payment throughput. Resiliency — kill the core connection mid-transfer and assert no partial or double debit (rollback or idempotent replay) with a graceful error. Disaster recovery — failover to standby, RTO/RPO, and data consistency after restore. And accessibility — WCAG/ADA, because banks are genuinely sued over it, so I run axe/Lighthouse in CI plus screen-reader passes on money flows.

Q15. You don't have banking experience — why should we hire you?

(Use the honest scripted line from §6.) I haven't worked inside a bank, but my work maps directly onto banking concerns: e-commerce payments and RestAssured API automation already deal with money precision, double-charge prevention, and declined paths; and my VAPT background means I reflexively test the highest-risk banking defects — authorization gaps where one user reaches another's accounts, and PII/card-number leakage. I've done the domain homework on ACH vs wire vs RTP, ledger-vs-available, and KYC, so I can frame my testing in banking terms from day one and ramp fast.

8. One-page recall sheet (drill before the call)¶

Re-skin every answer in banking terms. "Checkout" → "fund transfer". "Form" → "KYC onboarding".
8 concerns to drop unprompted: money math (BigDecimal, banker's rounding) · idempotency/double-debit · real-time + concurrency · security/entitlements/PII (your edge) · audit trail/reconciliation · compliance evidence/traceability · accessibility (ADA/WCAG) · resiliency/DR.
Available ≠ ledger. Holds reduce available, not ledger.
ACH = batch, slow, reversible-ish. Wire = instant, irreversible. RTP/FedNow = instant, final, 24/7.
Idempotency key prevents double-debit; replay the request to test it.
No real PII in lower envs (GLBA/PCI) → synthetic/test PANs, masked/tokenized data.
Mock the core + rails with WireMock; keep contract tests so mocks don't drift.
IDOR/BOLA: swap account IDs across users → must be 403. (Lead with your VAPT strength.)
Say "member" for credit unions.
Honest line: map real e-commerce/API/VAPT/data work onto banking; never claim bank employment.