82 banking domain interview questions with answers

What they are assessing

Basic orientation in the domain.

Model answer

The central system that holds customer accounts and processes the transactions against them: deposits, withdrawals, transfers, interest and fees, with the general ledger behind it. Everything else, meaning internet banking, mobile apps, ATMs and branch systems, are channels that ultimately post to it. Finacle, Flexcube, T24 and BaNCS are common examples. For a tester the significance is that the core is the system of record, so a defect there affects balances rather than only a screen.

Likely follow-up

What is the difference between a channel and the core?

What they are assessing

Whether the candidate sees why the domain is asked about at all.

Model answer

Because in banking the defects that matter are rarely interface defects. A screen that looks correct can post the wrong amount to the wrong ledger, apply the wrong value date, or calculate interest on the wrong day count basis, and none of that is visible without knowing what should have happened. Domain knowledge is what lets a tester say the balance is right but the accounting entry is wrong, which is the class of defect that produces regulatory findings rather than user complaints.

What they are assessing

A fundamental that candidates frequently get backwards.

Model answer

In double entry bookkeeping, a debit increases an asset or expense and decreases a liability, and a credit does the reverse. The confusion comes from the customer perspective: money arriving in your account is a credit to you and a liability to the bank, because the bank owes you that money. So a customer deposit is a credit on the customer statement and a credit to the bank liability account, balanced by a debit to the bank cash asset. Getting this orientation right is what lets you read a ledger entry and say whether it is correct.

Trap to avoid

Assuming debit always means money out. From the bank ledger perspective it means the opposite of what a customer sees on their statement, and that inversion is deliberately probed.

What they are assessing

A distinction with direct testing consequences.

Model answer

The ledger balance is the posted balance, reflecting transactions that have settled. The available balance is what the customer can actually use, which is the ledger balance adjusted for holds, uncleared funds, authorised but unsettled card transactions, and any overdraft facility. They diverge constantly and testing the wrong one produces false results. The specific cases worth testing are a card authorisation reducing available but not ledger, a cheque deposit increasing ledger on clearing but available only after the hold expires, and an overdraft making available exceed ledger.

Likely follow-up

What happens to available balance when a card authorisation expires unsettled?

What they are assessing

A concept unique to the domain.

Model answer

The date from which a transaction is effective for interest and balance calculation, which can differ from the transaction date when it was recorded and the posting date when it hit the ledger. A back-valued transaction is dated earlier than today, which forces interest to be recalculated for the intervening period. It matters because value date errors do not show on a balance at all: the balance is right and the interest accrued is wrong, which surfaces weeks later as a reconciliation break or a customer complaint.

What they are assessing

Breadth of product knowledge.

Model answer

Current and savings accounts, which differ in interest treatment and transaction limits. Fixed or term deposits, with maturity, premature withdrawal penalties and renewal rules. Recurring deposits. Loan accounts, which behave differently because the balance is owed rather than held. Overdraft and credit facilities. And internal accounts such as suspense, nostro and vostro accounts, which customers never see and which are where a surprising proportion of defects surface, because nobody looks at them.

What they are assessing

Awareness of where money goes when something fails.

Model answer

An internal holding account where transactions sit when they cannot be posted to their intended destination, typically because of an invalid account number, a mismatch or a failed validation. It matters because a transaction landing in suspense is usually a defect symptom rather than normal behaviour, so checking the suspense balance after a test cycle is one of the fastest ways to find problems nobody reported. A growing suspense balance in production is a known warning sign, and testing should include verifying that failed transactions reach it rather than disappearing.

What they are assessing

The core accounting principle applied to testing.

Model answer

Every transaction produces equal and opposite entries, so total debits equal total credits and the ledger always balances. Testing it means checking both sides of each transaction rather than only the customer visible one: a transfer debits one account and credits another, and a fee debits the customer and credits a bank income account. The check worth automating is the ledger balance assertion after a batch of transactions, since a one-sided posting is a serious defect that no customer-facing test would reveal.

Likely follow-up

What would a ledger that does not balance indicate?

What they are assessing

Correspondent banking vocabulary.

Model answer

A nostro account is our money held at another bank, typically in a foreign currency, and a vostro account is their money held with us. The terms describe the same relationship from the two sides. They matter in cross border payment testing because the settlement path runs through them, so a SWIFT payment involves movements across correspondent accounts rather than a direct transfer. Reconciliation of nostro accounts against the correspondent statement is a core operational control, and testing that reconciliation is a significant piece of work in international banking.

What they are assessing

A calculation with many ways to be subtly wrong.

Model answer

By testing the components rather than the output alone. The day count convention, since actual over 365, actual over 360 and 30 over 360 give different answers and the product documentation specifies which applies. The accrual frequency against the capitalisation frequency, which are different things. The balance the rate applies to, which may be daily closing, minimum monthly or average. Rate changes mid period, including whether the new rate applies from the change date or the next cycle. Leap years. And back-valued transactions forcing recalculation. I would verify against an independently calculated expected value rather than against the system output.

Trap to avoid

Testing only that interest was credited. The amount being approximately right hides day count and accrual errors that compound into material differences over a year.

What they are assessing

Indian payment rails, commonly asked.

Model answer

NEFT settles in batches through the day, so it is deferred net settlement and not instant. RTGS settles in real time gross, each transaction individually, and is used for high value payments with a minimum threshold. IMPS is immediate, available continuously including outside banking hours, and is used for lower value instant transfers. For testing, the differences that matter are timing and cut-offs, since a NEFT submitted after cut-off is processed in the next cycle or next working day, and that behaviour around cut-off boundaries is where the defects are.

Likely follow-up

What should happen to a NEFT submitted one minute after the final cut-off?

What they are assessing

Current payment infrastructure.

Model answer

A real time payment system built on a virtual payment address, so the payer does not need the recipient account number, with a mobile PIN authorising the transaction and a request to pay flow in both directions. Testing specifics include the VPA resolution step, the two legged collect flow where a request is raised and approved separately, transaction limits per transaction and per day, the behaviour when a payment is debited but the credit fails, which must reverse within a defined window, and the deemed acceptance rules for disputes. The failure and reversal paths matter far more than the happy path.

What they are assessing

Cross border payments.

Model answer

SWIFT is the messaging network banks use for cross border instructions, not a settlement system: it carries the message while settlement happens through correspondent accounts. The message types matter, with MT103 for a single customer credit transfer and MT202 for bank to bank, and the industry is migrating to ISO 20022 XML messages. For testing, the areas are message format validation, field level rules including mandatory and conditional fields, correct population of charges and intermediary bank fields, and sanctions screening before release, which can hold a payment.

What they are assessing

A core scenario, used to see how thoroughly they think.

Model answer

The happy path first: debit the correct account for the correct amount, credit the beneficiary, post both ledger entries, apply charges, update available and ledger balances correctly, produce the statement narration and the notification. Then the cases that matter more: insufficient funds including the overdraft boundary, an invalid or closed beneficiary account, limits at transaction and daily level, a transfer hitting a cut-off, duplicate submission and whether idempotency prevents a double debit, a failure after debit and before credit and whether it reverses, and the behaviour when the beneficiary bank rejects it after acceptance. The reversal paths are where the serious defects live.

Likely follow-up

What should happen if the system crashes between the debit and the credit?

What they are assessing

A concept with direct financial consequence.

Model answer

That repeating the same request produces the same result rather than performing the action twice, usually implemented with a client supplied reference the server checks before processing. It matters in payments because retries are routine: a timeout does not tell the client whether the payment succeeded, so the safe behaviour is to retry, and without idempotency that produces a duplicate debit. Testing it means submitting the same request twice with the same reference and verifying one transaction results, then submitting with a different reference and verifying two, and covering the case where the retry arrives while the first is still processing.

What they are assessing

The compensating path.

Model answer

Undoing a payment that should not have completed, which in banking is usually a compensating entry rather than deleting the original, because the audit trail must show both. Testing means verifying the reversal posts correct opposite entries, that it references the original transaction, that charges are reversed appropriately or deliberately not, that interest accrual is corrected if the value date differs, and that the customer statement shows both entries rather than the original disappearing. The subtle case is a partial reversal, and the one teams forget is a reversal of a transaction that has already been reversed.

What they are assessing

The card lifecycle, which candidates often collapse into one step.

Model answer

Authorisation is the real time check that the card is valid and funds or credit are available, which places a hold reducing the available balance without moving money. Settlement happens later, usually in a daily batch, when the merchant submits the transaction and funds actually move, posting to the ledger. They can differ in amount, as with a fuel pump pre-authorisation or a restaurant tip added afterwards. Testing must cover both and the gap between them, including an authorisation that is never settled and must expire, releasing the hold.

Likely follow-up

What is the customer impact if an expired authorisation hold is not released?

What they are assessing

Dispute handling.

Model answer

A reversal initiated by the cardholder bank on the customer behalf, disputing a transaction, which pulls funds back from the merchant. It follows a defined lifecycle with time limits: the chargeback, the merchant representment if they contest it, and potentially arbitration. For testing, the areas are the state transitions and whether invalid ones are prevented, the time limits and what happens at expiry, the provisional credit to the customer and its reversal if the dispute fails, and the accounting entries at each stage, which are easy to get wrong because money moves more than once.

What they are assessing

A compliance constraint with practical consequences.

Model answer

The Payment Card Industry Data Security Standard, governing how card data is stored, processed and transmitted. The consequence for testing is that real card numbers must not be used in test environments, and if cardholder data is present the environment falls into scope for the standard, which brings substantial control requirements. So test card numbers from the scheme test ranges are used instead, and production data copied to a test environment must have card data removed or tokenised rather than merely masked on screen. Primary account numbers must never appear in logs, which is a worthwhile thing to test for explicitly.

Trap to avoid

Treating card data in test as a privacy concern only. It changes the regulatory scope of the environment, which is a much larger consequence than a data protection issue.

What they are assessing

Boundary thinking applied to a layered rule set.

Model answer

By identifying every limit that applies, because there are usually several: per transaction, daily cumulative, monthly, per channel such as ATM against point of sale against online, per merchant category, and international against domestic. Then testing each boundary at the limit, just below and just above, and the interaction where a transaction is within the per-transaction limit but breaches the daily cumulative. The cases that find defects are the reset boundary, meaning what counts as a day and in which timezone, and whether a reversed or failed transaction correctly releases its contribution to the cumulative total.

What they are assessing

Loan mechanics.

Model answer

An equated monthly instalment, a fixed payment covering interest and principal where the interest portion falls and the principal portion rises over the term. Testing covers the EMI calculation itself against an independent computation, the amortisation schedule including the final instalment which usually differs due to rounding, the split between interest and principal each month, part prepayment and whether it reduces the term or the instalment, foreclosure and the charges applied, and rate changes on a floating rate loan and how they are absorbed. The final instalment rounding is a classic source of small persistent defects.

Likely follow-up

Why does the last instalment usually differ from the others?

What they are assessing

Regulatory classification in lending.

Model answer

A loan where the borrower has not made scheduled payments for a defined period, commonly ninety days of overdue interest or principal, after which the bank must classify it as non performing and make provisions against it. Classification tiers run from standard through substandard, doubtful and loss. For testing, the relevance is the automated classification logic: the day counting, the boundary at exactly ninety days, upgrade rules when the borrower regularises, and the provisioning entries that follow. Misclassification is a regulatory reporting error rather than a customer-facing one, which is why it needs deliberate testing.

What they are assessing

A long multi-stage process.

Model answer

As a state model, since it is a workflow with defined transitions: application, document collection, KYC, credit assessment including bureau enquiry, approval within delegated authority limits, sanction, disbursement and account creation. I would test each transition including the invalid ones, the approval authority boundaries where an amount just above a threshold must escalate, the rejection and resubmission paths, and what happens when an external service such as the credit bureau is unavailable. The integration points are where most defects sit, because each one has a failure mode the happy path never exercises.

What they are assessing

A universal banking control.

Model answer

Know Your Customer, the process of verifying customer identity and address before and during the relationship, with periodic re-verification based on risk category. Testing involves the document validation rules, the identity verification integration, the risk categorisation logic that determines re-verification frequency, and crucially the blocking behaviour: an account whose KYC has expired should be restricted, and testing that the restriction actually applies across every channel rather than only the one where it was implemented is the part most often missed.

What they are assessing

Anti money laundering controls.

Model answer

Anti money laundering, the controls detecting and reporting suspicious activity. The testable elements are transaction monitoring rules, such as thresholds triggering a report, structuring detection where several transactions sit just below a threshold, and unusual pattern detection. Then sanctions and politically exposed person screening against watchlists, including fuzzy name matching and how false positives are handled. And the regulatory reports produced, which must be accurate and timely. Testing these needs deliberately constructed data, because the patterns being detected do not occur naturally in a test environment.

Likely follow-up

How would you test structuring detection specifically?

What they are assessing

An area with no tolerance for error.

Model answer

By verifying it against the regulator specification rather than against what the system produces, which means reading the actual submission guidelines for field definitions, formats and validation rules. Then reconciling the report totals against the underlying ledger, since a report that is internally consistent and does not match the books is the serious case. Then boundary conditions on the reporting period, particularly transactions on the period boundary and back-valued entries that change a period already reported. And the submission format itself, since many are rejected on technical validation before anyone reads the content.

What they are assessing

A requirement that is assumed rather than tested.

Model answer

An immutable record of who did what and when, which in banking is a regulatory requirement rather than a convenience. It needs the actor, the action, the before and after values, the timestamp with timezone, and the channel or system of origin. For testing, the points that matter are that it cannot be altered or deleted through the application, that it captures failed and rejected attempts as well as successful ones, that privileged and maker-checker actions are recorded, and that sensitive values are not written into it in clear, which is a common defect where an audit log captures a full card number.

What they are assessing

A control specific to financial systems.

Model answer

A dual control requirement where one user initiates an action and a different user authorises it, so no single person can complete a sensitive operation. Testing it means verifying the same user cannot approve their own entry, including through a different channel or by using a privileged role, that the transaction has no effect until approved, that rejection returns it correctly with a reason, and that the approval limits by role are enforced. The defect to hunt for is a bypass path: an API or a batch route that performs the action without the second approval, which happens more often than it should.

Trap to avoid

Testing only the user interface path. Maker-checker is routinely bypassable through an API or an administrative function, and that is the finding worth having.

What they are assessing

Breadth of security awareness.

Model answer

Authentication strength including multi factor, session management with timeout and concurrent session handling, and authorisation checks ensuring one customer cannot access another account by changing an identifier, which is the single most common serious finding. Then input validation against injection, encryption in transit and at rest, secure handling of credentials and card data including absence from logs, and rate limiting against brute force. Penetration testing by specialists sits alongside this, but the authorisation checks are squarely within functional testing and are frequently not covered.

Likely follow-up

How would you test for broken object level authorisation?

What they are assessing

The most important security test in retail banking.

Model answer

By authenticating as one customer and then attempting to access another customer resources directly, substituting account numbers, customer identifiers and transaction references in API calls rather than through the interface, which usually prevents it through navigation alone. This must be done for every endpoint rather than a sample, because a single endpoint missing the ownership check is sufficient for a breach. I would also test it for internal users with limited scope, and for the case where a customer previously had access to a joint account that has since been closed to them.

What they are assessing

A regulatory requirement affecting payment flows.

Model answer

A requirement under regulations such as PSD2 in Europe that certain payments and account access use at least two independent factors from knowledge, possession and inherence. For testing, the work is in the exemptions as much as the rule: low value transactions, trusted beneficiaries, recurring payments and merchant initiated transactions may be exempt, and the exemption logic is where defects occur. Also worth testing is the cumulative counter, since consecutive low value exemptions must trigger authentication once a threshold is reached, which is a rule teams implement and rarely test at the boundary.

What they are assessing

A domain concept with no equivalent in most other sectors.

Model answer

A scheduled batch run that closes the business day: applying interest accrual, processing standing instructions, running settlement, revaluing positions, generating reports and rolling the business date forward. It matters because much of what a bank does happens here rather than in real time, so a feature can appear to work all day and fail at end of day. It also means testing requires the ability to run the batch and roll the date, which is an environment capability rather than a test design question, and one that is frequently the constraint on a test cycle.

Likely follow-up

What is the difference between the business date and the system date?

What they are assessing

A different shape of testing from transactional work.

Model answer

Volume first, because a batch that works on fifty records can fail on five hundred thousand through timeouts, memory or lock contention, and the production volume is the only one that matters. Then the error handling: what happens when one record fails, whether the batch continues or aborts, and whether a partial run leaves consistent data. Then restartability, which is the critical property, since a batch that fails at eighty percent must be resumable without reprocessing or double processing the first eighty. Then the processing window, since a batch exceeding its window delays everything downstream.

Trap to avoid

Testing a batch only with a small sample. Volume changes the behaviour, and restartability after a mid-run failure is the property most likely to be broken and least likely to be tested.

What they are assessing

A practical and awkward requirement.

Model answer

By having a way to control the business date in the test environment, which is usually a core banking capability rather than something to be achieved by changing the server clock, since that affects everything else sharing the environment. Then testing the boundary explicitly: transactions submitted just before and just after cut-off, interest accrual on the rollover day, month end and year end which have additional processing, and non working days including weekends and holidays, since a payment dated on a holiday must move to the next working day according to a defined convention.

What they are assessing

A core operational control.

Model answer

Comparing two independent records of the same activity to confirm they agree, such as the internal ledger against a correspondent bank statement, card scheme settlement files against the card ledger, or ATM cash dispensed against the switch records. A difference is a break, which must be investigated and resolved. For testing, reconciliation is both something to test, since the automated matching logic has rules that can be wrong, and a technique to use, since reconciling after a test cycle is one of the most effective ways to find defects nobody reported.

What they are assessing

Testing a matching engine.

Model answer

By constructing the cases the matching rules must handle: exact matches, matches within a tolerance, one to many and many to one where a single settlement covers several transactions, timing differences where an item appears in one source a day later, duplicates in either source, and genuine breaks. Then verifying that unmatched items are reported rather than silently dropped, which is the dangerous failure, and that the ageing of outstanding breaks is tracked. I would also test that a forced or manual match is recorded with a reason, since that is a control point auditors examine.

Likely follow-up

Why is a silently dropped unmatched item worse than a reported break?

What they are assessing

A constraint that shapes the whole engagement.

Model answer

Because the states you need take time to create naturally. A loan ninety days overdue, an account with twelve months of interest history, or a dispute at the arbitration stage cannot be created by clicking through the interface. Data also has to be internally consistent across the ledger, which rules out inserting records directly without understanding the model. And real customer data cannot be used without masking because of privacy regulation, while masking must preserve referential integrity and realistic distributions or the data becomes useless for testing.

What they are assessing

A concrete version of the previous problem.

Model answer

Not by waiting. The options in order of preference are: run the batch and roll the business date forward in a dedicated environment, which produces genuinely consistent data through the real processing path and is the only approach that tests the logic as well as creating the state. Or back-date the account opening and payment schedule so the account is already overdue relative to the current business date. Or construct the data directly, which is fastest and risks inconsistency because the ledger, the schedule and the classification tables must all agree. The first is correct where the environment permits it.

What they are assessing

A compliance constraint rather than a preference.

Model answer

It generally cannot be used unmasked. Personal data is covered by privacy regulation such as GDPR, card data brings the environment into PCI DSS scope, and financial data is subject to banking secrecy obligations in most jurisdictions. So production copies must be masked or synthesised, with masking preserving referential integrity so relationships still work and preserving realistic distributions so performance characteristics hold. Access to any environment containing even masked production-derived data is usually restricted and logged, which is a practical constraint on who can test what.

What they are assessing

Awareness of the wider landscape.

Model answer

Payment networks and clearing systems, card schemes and the switch, credit bureaus, KYC and identity verification providers, sanctions screening services, the central bank for reporting and settlement, SMS and email gateways for notifications, and often a separate general ledger. Each one is a boundary where the failure modes matter more than the happy path, and several of them are systems you have no control over and cannot load test, so service virtualisation becomes necessary rather than optional.

What they are assessing

Integration testing in a high consequence context.

Model answer

The message format and field level rules first, which can be verified without the real network. Then the response handling: success, business rejection, technical failure, and the one that matters most, no response at all, since a timeout leaves the payment in an unknown state and the recovery behaviour is what determines whether a customer is debited twice. Then reconciliation against the settlement file. I would use a simulator or the network test facility rather than production, and I would deliberately test the uncertain outcome path, because it is both the most likely to be wrong and the most expensive when it is.

Likely follow-up

What should the system do when a payment request times out with no response?

What they are assessing

A technique the domain forces on you.

Model answer

Simulating an external dependency with a configurable stand-in reproducing its interface, latency and error behaviour. It is necessary in banking because many dependencies cannot be used freely: credit bureau enquiries cost money per call, sanctions screening providers rate limit, payment networks have restricted test facilities, and none of them can be load tested without permission. Virtualisation also lets you produce the failure conditions that matter, such as a timeout or a malformed response, which the real sandbox will not produce on demand and which are exactly the cases that need testing.

What they are assessing

Risk assessment in a specific domain.

Model answer

By financial and regulatory consequence rather than by feature visibility. The highest priority is anything that moves money or affects a balance, because the consequence is irreversible and customer facing. Then regulatory reporting and compliance controls, because the consequence is a finding rather than a complaint. Then the batch and end of day cycle, because a failure there affects everything. Then channels, which are more visible and more recoverable. A cosmetic defect in internet banking is an inconvenience; a rounding error in interest accrual is a remediation exercise across every affected account.

What they are assessing

A phase that carries unusual weight in this domain.

Model answer

Acceptance testing performed by the business users who will operate the system: branch staff, operations, treasury, compliance and finance, using realistic scenarios and often their own data. It carries more weight in banking than elsewhere because the domain knowledge needed to recognise a wrong accounting entry or an incorrect regulatory treatment sits with those users rather than with the testing team. The failure mode is treating it as a second system test run by business users, which wastes the one thing they uniquely offer, which is judgement about whether the behaviour is actually correct for the business.

Likely follow-up

What would you provide to business users to make UAT effective?

What they are assessing

A realistic view of a constrained environment.

Model answer

More than teams usually achieve, and less than in a web product. API and service level automation works well and should carry most of the load, since the core exposes services and they are stable. Ledger and calculation verification automates well because the expected results are computable. What resists automation is anything requiring a date roll and a batch cycle, green screen or thick client interfaces on older core systems, and workflows spanning several systems with manual operational steps. The honest position is to automate the regression that can be automated and accept that a banking release still carries substantial manual and business verification.

What they are assessing

The largest and riskiest work in the domain.

Model answer

Data migration is the centre of it, so I would plan reconciliation as the primary verification: every account, every balance and every outstanding transaction accounted for between the old and new systems, with totals agreeing at the ledger level and at the individual account level. Then parallel running, where both systems process the same activity and the outputs are compared, which is the only way to gain real confidence. Then the cutover rehearsal, timed and practised including the rollback. Functional testing of the new system matters, but on a migration the risk concentrates in the data and the cutover rather than in the features.

Likely follow-up

What would make you recommend delaying a go-live?

What they are assessing

Behaviour under pressure in a high consequence environment.

Model answer

Confirm it on the release candidate in a production-like environment, since a defect only reproducible on an outdated test environment changes the conversation. Establish the consequence precisely: does it affect balances, does it affect regulatory reporting, is it reversible, how many customers, is there a workaround. Write that up factually and escalate immediately rather than investigating quietly, because the decision needs time. In banking the financial and regulatory dimensions change the calculus: a defect producing incorrect postings is usually not shippable even with a workaround, because unwinding it afterwards is a remediation project rather than a fix.

What they are assessing

Communication to a risk-focused audience.

Model answer

In terms of risk and consequence rather than test counts. What was tested and to what depth, what was not and why, the open defects with their financial and regulatory impact, and a clear recommendation with the reasoning. The audience cares about whether money could move incorrectly, whether a regulatory obligation could be missed, and whether anything is irreversible, so those should be the headings. A percentage of tests passed invites a false sense of completeness and will be read optimistically, whereas naming the untested areas explicitly is what allows an informed decision.

What they are assessing

A common recurring feature.

Model answer

An instruction to make a payment automatically on a schedule, such as a monthly transfer or a loan repayment. Testing covers the schedule calculation including month ends where the 31st does not exist in every month, execution on a non working day and whether it moves forward or back, insufficient funds behaviour including whether it retries and how many times, the order of execution when several fall due on the same day, amendment and cancellation including mid-cycle, and expiry. The month end date handling is a reliable source of defects.

What they are assessing

An end-of-lifecycle scenario frequently under-tested.

Model answer

By checking the preconditions and the consequences. The account should not close with a non zero balance, outstanding holds, unsettled card authorisations, active standing instructions or a linked loan. On closure, the residual balance must be paid out correctly with any interest accrued to the closure date, the account must become inaccessible across every channel rather than just the one tested, and any linked cards must be deactivated. The cases that find defects are a transaction arriving after closure and whether it is rejected or lands in suspense, and reopening if the product permits it.

Likely follow-up

What should happen to a direct debit presented against a closed account?

What they are assessing

A corporate banking scenario.

Model answer

File level first: format validation, header and trailer checks, the record count and control total matching the contents, duplicate file detection by reference, and file size at the stated maximum. Then record level: valid records processing, invalid records rejected, and crucially whether one bad record rejects the whole file or only itself, which is a business rule that must be explicit. Then the aggregate: whether the total debited matches the control total, and whether partial processing leaves a consistent state. Then authorisation, since bulk files usually require maker-checker before release.

What they are assessing

Control behaviour.

Model answer

An attempt to transact beyond a configured limit, which should be rejected with a clear message rather than silently truncated or partially processed. The behaviours worth testing are that the rejection happens before any debit, that the attempt is logged since repeated breaches may be a fraud signal, that the limit is enforced server side rather than only in the interface, and that it is enforced consistently across channels. The last point is the common defect: a limit enforced in the mobile app and not in the API behind it is a control that does not exist.

Trap to avoid

Testing limits only through the user interface. A limit that is only a client side check is not a limit, and verifying it at the API is the test that matters.

What they are assessing

A small feature with security significance.

Model answer

That they are sent for every event that requires one, since notification of a debit is a fraud detection control rather than a convenience, and a missing notification is a security defect. Then that they go to the registered contact rather than one supplied in the request, that a change of registered contact itself triggers a notification to the old address, which is a standard account takeover control, and that sensitive detail such as a full account number or card number is not included. Timing matters too, since a notification arriving an hour later defeats its purpose.

What they are assessing

Boundary testing in the domain.

Model answer

The deadline after which a transaction is processed in the next cycle or next business day rather than the current one. Testing it means submitting just before, exactly at, and just after the cut-off and verifying the value date and processing cycle assigned to each. The cases that find defects are the timezone used, since a bank operating across regions may apply a single cut-off in one timezone, the behaviour on a non working day, and a transaction submitted before cut-off but still in an approval queue when the cut-off passes, which is a genuinely ambiguous case the business must decide.

What they are assessing

A calculation with several valid outcomes.

Model answer

By establishing which outcome the product specifies, because a prepayment can reduce the instalment keeping the term, or reduce the term keeping the instalment, and some products let the customer choose. Then testing the recalculated schedule against an independent computation, the interest adjustment for the period, any prepayment charge and whether it is permitted at all within a lock-in period, and the treatment when the prepayment exceeds the outstanding principal. I would also test a prepayment made on the instalment due date, since the ordering of the two postings determines the interest charged.

What they are assessing

A concrete reconciliation case.

Model answer

Matching cash physically dispensed by an ATM against the transactions recorded by the switch and posted to customer accounts. What goes wrong is the partial dispense or failed dispense: the customer is debited and the cash does not come out, or comes out partially, and the reversal must be triggered by the reconciliation rather than by the customer complaining. Testing covers the dispense failure path, the timeout where the switch does not learn the outcome, and the automatic reversal within the mandated window, which in several jurisdictions carries a compensation obligation if missed.

What they are assessing

A small topic with large consequences.

Model answer

By establishing the specified rounding rule, since half up, half even and truncation give different results, and the regulatory or product documentation usually specifies which. Then testing values that sit exactly on the boundary, which is where the rules differ. Then testing the accumulation, because rounding applied per transaction and rounding applied to a total give different answers, and over a large portfolio the difference is material. And verifying the precision stored, since a system holding two decimal places while calculating at higher precision will produce drift between the calculated and posted values.

Trap to avoid

Testing rounding with ordinary values. The only values that find rounding defects are the ones that land exactly on the halfway point.

What they are assessing

A mechanism affecting balances without moving money.

Model answer

An amount reserved on an account so it cannot be used, reducing the available balance without changing the ledger balance. Holds arise from card authorisations, cheque clearing, legal orders and internal risk decisions. Testing covers the hold being applied and released correctly, expiry after the defined period, the interaction with other holds where several apply at once, whether a hold can push available below zero, and the behaviour when a transaction is attempted against held funds. A hold that is never released is a customer-facing defect that is easy to produce and hard to notice in testing.

What they are assessing

Resilience in a system where failure is expensive.

Model answer

By simulating the unavailability rather than waiting for it, and verifying the channel behaves safely: no transaction accepted that cannot be completed, a clear message rather than a generic error, no state left partially committed, and queued requests handled correctly on recovery without duplication. The specific risk in banking is the channel accepting a payment it cannot post, so the question I would focus on is whether the customer could be given a confirmation for something that never happened, which is both a customer harm and a reconciliation problem.

What they are assessing

A regulatory requirement with a testable surface.

Model answer

Banking regulation mandates retaining transaction and customer records for defined periods, commonly five to ten years, while privacy regulation requires deletion once the basis for holding data ends, so the two pull in opposite directions and the resolution is product and jurisdiction specific. For testing it means verifying that archival and purge processes retain what must be retained and remove what must be removed, that archived data remains retrievable in the required format, and that a customer deletion request is handled correctly given the overriding retention obligation, which usually means restriction rather than deletion.

What they are assessing

A frequently used feature with security consequences.

Model answer

That the block takes effect immediately across every channel including offline-capable transactions where possible, that it distinguishes a temporary block from a permanent one, and that an in-flight authorisation already approved still settles, since blocking does not reverse an existing authorisation. Then unblocking: whether it requires additional authentication, whether it is permitted after a fraud block, and whether recurring merchant transactions resume. The case to test specifically is a transaction attempted in the window between the block being requested and being propagated to the switch.

What they are assessing

A practical constraint in large programmes.

Model answer

Through allocation rather than coordination, because coordination fails as soon as people are busy. Accounts and customers are reserved per team or per tester, documented, and not used by anyone else, since another team transacting on your account invalidates your expected balance. Where that is not possible, each test creates its own customer and accounts through an API or batch, which is the stronger approach. The other necessity is a known refresh schedule, since the worst version of this problem is a database restore mid-cycle that nobody announced.

What they are assessing

A fraud control with testable behaviour.

Model answer

A delay between adding a new payee and being able to transfer to them, or a reduced limit during that window, which exists to limit the damage from an account takeover. Testing it covers the period boundary, the reduced limit during the window, whether the restriction is enforced server side across channels, and the notification sent when a beneficiary is added, which is the detection control that makes the delay useful. Also worth testing is whether an existing beneficiary modified to a different account number is treated as new, which it should be and often is not.

Likely follow-up

Why should editing a beneficiary account number reset the cooling period?

What they are assessing

Prioritisation under a hard constraint.

Model answer

By scoping to the obligation rather than to the full feature set, since the deadline applies to the regulatory requirement and not to everything shipped alongside it. I would establish precisely what the regulation requires, test that to full depth including the reporting output and the evidence an auditor would ask for, and be explicit that other changes in the release carry less coverage. Then I would push for the non-regulatory scope to be reduced, since the common failure is a regulatory deadline being used to ship unrelated work with insufficient testing under cover of the same date.

What they are assessing

A lifecycle state with regulatory treatment.

Model answer

An account with no customer-initiated activity for a defined period, commonly one or two years, after which it is classified dormant and transactions are restricted until the customer reactivates it, usually through re-verification. Longer inactivity may lead to the balance being transferred to a regulator-managed fund. For testing, the areas are the inactivity calculation and what counts as activity, since interest credit usually does not, the restriction being applied across all channels, the reactivation process, and the notification sent before classification, which is normally a regulatory obligation.

What they are assessing

A security area with concrete test cases.

Model answer

Timeout after inactivity and whether it is enforced server side rather than by a client timer, which is the common defect. Session invalidation on logout, including that the token cannot be reused afterwards. Concurrent sessions, and whether the product permits them or should terminate the older one. Session fixation, meaning the token must change on authentication. Token transmission only over secure channels and not in a URL. And behaviour on password change, which should invalidate other sessions, since that is the control a user relies on after suspecting compromise.

What they are assessing

Practical selection in a high risk domain.

Model answer

Always the money movement paths regardless of what changed, because the consequence is irreversible: transfers, payments, card transactions and the ledger postings behind them. Then the end of day batch, since almost any change can affect it. Then the areas touched by the release and anything sharing code or data with them. Then a rotating sample across the rest. The non-negotiable core is larger in banking than in most domains, because the cost of a regression in posting logic is not a defect report but a remediation across affected accounts.

What they are assessing

A product variation with real complexity.

Model answer

An account with more than one holder, with an operating mandate specifying whether any holder can transact alone or whether all must authorise. Testing specifics are the mandate enforcement, which is the core rule, visibility of the account to each holder including in their aggregate position, what happens when one holder is blocked or deceased, and whether a holder removed from the account retains any access, including historical statements. The mandate requiring joint authorisation is the case most likely to be implemented in one channel and missed in another.

What they are assessing

Learning from a production incident.

Model answer

Whether restartability was ever tested, which it usually was not. The specific questions are whether the batch can resume from the failure point, whether rerunning from the start would double process the records already handled, and whether the partial state is identifiable. Those are testable in a lower environment by deliberately failing the batch mid-run, which is uncomfortable to arrange and is exactly the test that would have prevented the incident. I would add it to the regression set rather than treating the incident as a one-off, since the condition will recur.

What they are assessing

A specific compliance control.

Model answer

An individual holding a prominent public function, along with close associates and family, who presents higher corruption risk and therefore requires enhanced due diligence rather than refusal. Screening matters because failing to identify one is a regulatory breach. For testing, the interesting behaviour is name matching: it is fuzzy by necessity, so the test cases are name variants, transliterations, partial matches and the false positive handling workflow, since a screening system that matches too aggressively creates an operational burden that leads to alerts being cleared without review.

What they are assessing

A calculation with several moving parts.

Model answer

The rate source and the timestamp of the rate applied, since a rate fetched at request time and a rate applied at settlement produce different amounts and the product must specify which governs. The margin or spread added to the interbank rate, which is a revenue line and must be correct. Rounding in the converted amount, at the precision of the target currency, noting that not every currency has two decimal places. The charges and whether they are shared, borne by sender or borne by beneficiary, which changes what arrives. And the accounting entries, since conversion creates a position the bank must record.

Likely follow-up

Which currencies would you deliberately include in test data and why?

What they are assessing

Capability building.

Model answer

Domain knowledge is the constraint rather than testing skill, so I would address that first: pair testers with operations and finance staff, get them access to the real processes, and build a reference set of the calculations and rules they must know. In parallel, prioritise automation at the service and ledger layer, because that is where verification is most valuable and most automatable. And establish the environment capability early, specifically the ability to roll the business date and run the batch, since without it a large part of the system cannot be tested at all and no amount of skill compensates.

What they are assessing

Applying a domain control to the testing process.

Model answer

Because it finds the defects nobody reported. After a test cycle, verifying that the ledger balances, that every transaction has two matching entries, that the suspense account is empty and that the sum of customer balances agrees with the control account will surface one-sided postings, rounding drift and orphaned transactions that no functional test case targeted. It is a whole-of-system check rather than a case-based one, which is why it catches a different class of problem, and it costs very little once scripted.

What they are assessing

Product distinction with technical consequences.

Model answer

A debit card transaction checks and reserves funds in a deposit account, so available balance and holds are central. A credit card transaction checks against a credit limit on a loan-like account, so the concepts are available credit, billing cycle, statement generation, minimum payment, grace period and interest on revolving balance. The testing therefore diverges substantially after authorisation: debit is about balance and holds, credit is about the billing cycle and interest calculation, and the statement period boundary is where most credit card defects appear.

What they are assessing

Professional boundaries.

Model answer

I would not frame it as refusal, since the release decision belongs to the business and my role is to make the risk clear. What I would escalate as not recommended for release is anything producing incorrect postings or balances, because the consequence is irreversible and the remediation is disproportionate. Anything breaching a regulatory obligation. Anything where the failure mode is silent, since a defect nobody detects accumulates. And anything untested that I believe carries material risk, where the honest statement is that I cannot advise on it rather than that it is broken.

What they are assessing

A feature that became prominent and is frequently defective.

Model answer

A payment holiday where instalments are deferred for a period, with interest usually continuing to accrue and being capitalised or added to the term afterwards. Testing covers the schedule recalculation after the moratorium, whether interest accrued during it is capitalised correctly, the effect on the loan classification since a moratorium should not trigger non performing classification, the end of the moratorium and the resumption of instalments, and a prepayment or closure requested during it. The classification interaction is the one with regulatory consequence.

What they are assessing

A specific and costly external dependency.

Model answer

With a virtualised bureau for most testing, because real enquiries cost money and leave a footprint on the subject credit file, which is not acceptable for test data. The cases are the response variants: good file, thin file, no match, multiple matches requiring disambiguation, and a file with adverse information that should change the decision. Then the failure modes: timeout, service unavailable, and malformed response, with particular attention to whether an unavailable bureau blocks the application or allows a manual override, since that is a business decision that must be explicit.

What they are assessing

A deceptively simple artefact.

Model answer

A periodic record of transactions and balances for an account. Testing covers the opening and closing balance reconciling with the transactions listed, the period boundary including transactions on the first and last day, ordering and the treatment of transactions on the same day, the narration being meaningful and not exposing internal codes, back-valued transactions appearing in the correct period, and the balance carried forward matching the previous statement. The reconciliation of opening plus movements equals closing is the single most valuable check and the one most likely to be omitted.

What they are assessing

Date-driven behaviour change.

Model answer

By testing on both sides of the effective date, which requires date control in the environment. Transactions before the date must follow the old rule and after it the new one, and the case that matters is a transaction back-valued to before the effective date after the change has gone live, which should normally follow the old rule. Also worth testing is reporting that spans the boundary, where a reporting period contains both treatments. The deployment question is separate and worth raising: whether the code ships before the date with the rule gated on it, or ships on the date, since the first is far safer and needs the gate tested.

What they are assessing

Judgement about a genuine tension.

Model answer

By differentiating rather than applying one standard. Not everything in a bank carries the same consequence: a change to marketing content on the internet banking homepage does not warrant the rigour that a change to interest accrual does. So the strategy should define tiers by consequence, with money movement, ledger posting and regulatory reporting held to the highest standard with no flexibility, and lower-consequence changes moving faster with lighter verification. That is what allows pace without pretending the risk is uniform, and it is a more defensible position than arguing for the same depth everywhere.

What they are assessing

A synthesising question.

Model answer

Irreversibility and consequence. In most domains a defect produces a bad experience that can be fixed forward. In banking a defect can move money incorrectly, and unwinding it means a remediation exercise across every affected account, potentially with regulatory reporting and customer compensation. That changes the economics: the effort justified to prevent a posting defect is far higher than for an equivalent defect elsewhere. It also means the quiet defects matter more than the visible ones, because a wrong calculation that nobody notices for six months is worse than an outage that everyone sees immediately.

What they are assessing

A closing question revealing depth of experience.

Model answer

Testing the channel and not the ledger. A tester verifies the screen shows the right balance and the transaction appears on the statement, and never checks the accounting entries behind it, so a one-sided posting, a wrong ledger account or an incorrect value date passes through. Those are precisely the defects that produce reconciliation breaks and regulatory findings months later. Close behind is testing only the happy path on reversals and failures, when in payments the failure paths are where the money actually goes missing, and they are exercised far more often in production than anyone expects.