Bank Pentest Test Data: Prepare the Accounts, States and Evidence That Matter

Bank penetration testing starts with testable business boundaries

A bank penetration test becomes more useful when the team can exercise the boundaries that protect customers, accounts and transactions. That requires more than a hostname and one login. It requires a carefully prepared set of identities, synthetic records, transaction states and expected outcomes. Without those inputs, the assessment may spend valuable time resolving access problems or produce broad claims from a very narrow sample.

This guide helps banking teams prepare test data and define coverage acceptance before testing begins. It is designed for application owners, security teams and procurement reviewers who need a practical answer to “what must we provide?” The examples are fictional and describe authorised testing with synthetic records. They are not instructions to transact with real customers, bypass production safeguards or treat a staging result as proof of production security.

Our bank penetration testing work focuses on the controls that protect the business operation. For banking applications, that includes customer separation, delegated authority, transaction integrity and session behaviour. Use this guide alongside the bank pentest scoping brief to turn those broad objectives into inputs that a testing team can actually use and a bank can later verify.

Define the objects before creating the accounts

Begin by listing the business objects that the application handles: customers, legal entities, accounts, beneficiaries, payment instructions, statements, support cases and administrative settings. For each object, identify its owner and the legitimate relationships that permit access. A corporate customer may contain several users with different authorities; a support user may see limited information across customers; a payment may require approval from a separate role.

Translate those relationships into a small but deliberate synthetic dataset. Create at least the distinct boundaries needed for the agreed tests rather than a large volume of identical records. Two customers with different ownership and permissions can reveal more than a thousand records under one account. The number of records should follow the test objectives, not an arbitrary preference for realism.

Document what each record represents. A test account named “user2” is easy to misuse if nobody knows whether it is a second customer, a second user of the same customer or an administrator. Use stable identifiers and a separate restricted reference sheet describing ownership and intended permissions. Avoid embedding sensitive credentials in the general test-data register.

Prepare role pairs that make negative tests meaningful

For every important permitted action, identify a closely related identity that should not be allowed to perform it. A maker and checker pair tests separation of duties. Two users with the same role under different customers test ownership separation. A read-only user and an operator test action permissions. These pairs make it possible to change one relevant condition while keeping the rest of the workflow comparable.

Provide separate credentials and any required authentication arrangements through the agreed secure channel. Confirm that the testing team can use the accounts without violating internal restrictions on devices, telephone numbers or simultaneous sessions. If a shared authentication device prevents two roles from being exercised independently, solve that before the scheduled test rather than accepting a reduced boundary as unavoidable.

Record the source of each permission. Is it assigned directly, inherited through a group, delegated by a customer administrator or controlled by a backend service? The visible role label may not describe the effective authority. Give the team enough context to formulate the expected result, while preserving the distinction between configuration information supplied by the bank and behaviour independently observed during testing.

Include lifecycle cases when relevant: newly invited, disabled, expired or recently changed roles. A normal active account covers only one point in the identity lifecycle. Agree which transitions can be exercised safely and who will perform administrative changes. Do not allow testers to improvise account suspension or privilege changes in production without the explicit operational arrangement.

Prepare transaction states without moving real money

A transaction workflow contains more security boundaries than its final submit button. Draft creation, beneficiary selection, approval, scheduling, cancellation, execution and reconciliation may each use different services and permissions. Prepare synthetic instructions in the states necessary for the agreed tests. Identify which states can be created through the ordinary interface and which require controlled setup by the application owner.

Use a sandbox or an agreed production-safe mechanism that prevents real settlement and unintended customer impact. The arrangement must be verified rather than assumed from a label such as “test account.” Confirm which downstream systems receive the instruction, whether notifications are sent and whether any external processor can act on it. Record the stop authority and the person who can reconcile unexpected state changes.

For each state, document the permitted next transitions and the fields that should remain bound to an approval. An approved amount, beneficiary or execution date should not be treated as interchangeable with a later changed value. The exact business rule depends on the bank’s design, but the expected relationship must be stated before testing. Otherwise a disagreement about business intent can be mistaken for a technical finding.

Preserve initial and final state evidence for each meaningful case. A rejected request is useful, but it may not prove that no background job or ledger change occurred. Where the scope includes such verification, have the owner inspect the relevant authoritative state. The test record should explain what was checked and what remained outside visibility.

Build a coverage matrix that reflects the application

Organise coverage around workflows, identities, objects and channels. A row might describe a corporate maker creating a payment through the web application, followed by a checker approving it through a mobile client. Another might examine a read-only user retrieving a statement through the API. This makes the assessment specific enough to reveal missing combinations without pretending every possible permutation can be tested.

Prioritise combinations with distinct enforcement paths. If mobile and web call the same backend operation, that is useful context but not proof that all client-specific handling is equivalent. Conversely, repeating identical cases across many cosmetic screens may add little value. Ask the team to explain its sampling rationale and identify where different services, permissions or state transitions justify separate cases.

Use the OWASP Web Security Testing Guide as a technical reference rather than as a substitute for business scope. Its testing topics can help organise checks, but the bank still needs to identify its own roles, objects and workflows. Record the version and the relevant coverage instead of claiming that a framework name means every application-specific risk has been examined.

Run a readiness check before the testing clock starts

Hold a short readiness session with the application owner and the testing lead. Confirm access, account roles, synthetic data, environment version, test windows, contacts and logging arrangements. Exercise one ordinary permitted workflow from start to finish. If the team cannot complete the legitimate operation, a later negative result may simply reflect broken setup rather than an effective security control.

Verify environmental restrictions explicitly. VPN access, IP allowlisting, client certificates, device registration or regional controls can prevent the test from reaching the intended boundary. Record which restrictions are part of the security assessment and which are merely access prerequisites. Do not remove a relevant control for convenience without documenting how that affects the interpretation of the results.

Check that evidence can be correlated. Agree request or transaction identifiers, time conventions and the owner who can inspect backend state when necessary. Confirm that the relevant logs will remain available long enough for reporting and clarification. If a short retention period makes later reconstruction impossible, resolve collection arrangements before executing the case.

Use a clear readiness decision. Ready means the agreed minimum inputs are available. Partially ready means specific work can proceed while identified dependencies remain open. Not ready means starting would materially reduce coverage or create unacceptable ambiguity. This language is more useful than beginning on schedule and quietly shrinking the scope to whatever happens to work.

Keep realistic data synthetic and identifiable

Synthetic data should resemble the relationships and formats required by the application without representing real customers. Mark it clearly enough that operations teams can recognise it during an investigation. Where identifiers must satisfy format validation, generate approved test values through the bank’s process. Do not copy a production customer record and assume that changing the name removes all sensitive content.

Review free-text fields, attachments and exported documents. These often contain unexpected personal or operational information even when the main database fields have been sanitised. If a realistic statement or support attachment is necessary, create a synthetic version designed for the test. Keep the source and purpose documented so that an analyst does not mistake it for a real customer document.

Decide how test data will be cleaned up and what evidence must remain. Removing all records immediately may make reporting or retesting difficult; retaining everything indefinitely creates unnecessary exposure. Agree the lifecycle with the owner, including any records that must remain for reconciliation or audit purposes. The testing team should not choose retention or deletion rules independently.

Minimise what appears in the report. A finding can often be demonstrated with redacted identifiers, a short response extract and a clear explanation of the affected boundary. Avoid including full customer-like datasets simply to show impact. The report should support remediation and verification without becoming a new repository of sensitive material.

A worked planning example: corporate payment approval

Consider a fictional bank application with two corporate customers, each with a maker and checker. Customer A has a synthetic draft payment and a separate approved beneficiary. Customer B has an unrelated account and beneficiary. Settlement is disabled through an owner-verified mechanism, and the bank provides a reconciliation contact. The objective is to assess whether ownership and approval boundaries hold across the application and its API.

The positive case establishes that Customer A’s maker can create an instruction and its checker can approve the permitted version. The negative cases then vary one boundary at a time: an unrelated customer, a read-only role, an instruction in the wrong state or a changed approved field. The exact requests remain within the agreed authorisation and test plan. The important design principle is controlled comparison, not aggressive volume.

For each case, capture the initial state, actor, intended operation, response and final state. If the application rejects a request but changes a background record, the evidence should show both observations. If the team lacks visibility into a downstream system, state that limitation instead of concluding that no effect occurred. The owner may supply a controlled state check without giving testers unrestricted access to the whole ledger.

At the end, reconcile all synthetic instructions against the expected states. Confirm that no unintended notifications, exports or scheduled jobs remain. Preserve the case identifiers needed for reporting and agree cleanup. This small discipline turns a collection of application requests into an assessment that the bank can understand, reproduce and safely close.

Handle unavailable inputs as explicit coverage decisions

Some inputs will be unavailable. A supplier may not provide a test tenant, a legacy role may be difficult to reproduce, or an external approval step may have a narrow window. Record the missing input, the affected question and the proposed alternative. Do not simply remove the case from the matrix and let the final report imply that the entire workflow was covered.

Evaluate alternatives by what they can prove. A design review may clarify intended enforcement but does not show observed behaviour. A staging test may exercise the workflow while differing from production configuration. A supervised owner-operated step may provide useful evidence while limiting independent exploration. State these distinctions so the reader understands the strength and boundary of the conclusion.

Give the bank a decision before the limitation becomes irreversible. It may choose to supply additional access, reschedule a case, accept reduced coverage or commission a follow-up. Those are legitimate choices when informed. They become problematic only when the scope is reduced without a clear owner and the report continues to use broad assurance language.

Keep a short coverage exception register in the final deliverables. Include cases not tested, cases partially tested and cases blocked by environmental problems. This is not an admission that the engagement failed. It is evidence that the team understands what it observed and refuses to turn missing evidence into a reassuring assumption.

Agree what the bank will accept as delivery evidence

Before work begins, define the expected report structure and coverage summary. Ask for the tested workflows, relevant identities, major boundaries, environmental constraints and finding evidence. A report consisting only of vulnerability entries may leave the bank unable to determine whether an important workflow was assessed and found sound or was never exercised at all.

For findings, require a clear affected boundary, reproducible evidence within the authorised environment, business impact and remediation direction. For effective controls, a concise coverage statement can explain what was observed without creating an enormous catalogue of successful checks. The report should balance technical detail with the decisions the bank needs to make.

Avoid accepting “zero findings” as a standalone success criterion. It may reflect effective controls, limited coverage, unsuitable data or insufficient time. The acceptance discussion should examine coverage and limitations alongside findings. Likewise, a high finding count is not automatically evidence of a better test. Relevance, evidence quality and the ability to support remediation matter more than volume.

Preserve the inputs needed for a meaningful retest

A retest needs a comparable boundary, not necessarily a byte-for-byte copy of the original environment. Preserve the affected role relationships, relevant synthetic objects, original case identifiers and the expected corrected behaviour. If the application changes materially, explain how the new workflow maps to the original finding. Otherwise the retest may check a different condition and incorrectly appear to close the issue.

Include a legitimate-operation check alongside the negative case. A fix that blocks every payment may prevent the original abuse while breaking the banking function. Verify that the authorised role can still complete the intended action and that the disallowed role or state cannot. Record any relevant residual path rather than treating the original request’s failure as complete remediation.

Coordinate data restoration carefully. A previously approved instruction may no longer be suitable for a fresh test, and a disabled account may have inherited new permissions during the interval. Revalidate prerequisites instead of assuming they remain unchanged. Keep the retest scope and environment version visible in the closure evidence.

Where a finding cannot be retested, state that directly. The bank may review implementation evidence or accept residual risk, but those decisions should not be labelled as an observed technical pass. Clear distinctions make the report more useful to developers, risk owners and later assessors.

Verify resets before reusing a synthetic case

A reset should restore the relevant business relationships, not merely change the visible status label. Confirm that approval history, scheduled work, generated documents and downstream references are consistent with the new starting condition. If the application cannot safely reset an instruction, create a fresh one and retain the old reference for evidence. Record which approach was used. This prevents a later case from inheriting hidden state and producing a misleading result. It also gives the owner a clear way to distinguish a genuine security observation from a test artefact caused by incomplete preparation.

Assign one owner for the test dataset

Nominate a dataset owner who can explain the records, approve resets and coordinate cleanup. This prevents several teams from changing the same synthetic customer during an assessment. Keep a lightweight change log for resets, permission changes and newly created instructions. If the dataset changes unexpectedly, pause the affected case and re-establish its prerequisites. The testing team should not have to guess whether a surprising result came from the application or from another person modifying the test account. A clear owner saves time and makes the evidence more dependable.

Keep the final dataset references available for review

Before cleanup, confirm that report reviewers can still interpret the synthetic identifiers and state transitions. Preserve a restricted reference extract where appropriate, without retaining credentials or unnecessary data. The extract should explain which customer, role and instruction each case represented. This allows an owner to challenge or reproduce a finding after the testing window closes. If the environment must be removed immediately, agree another controlled way to retain the relevant evidence and state the resulting retest dependency.

What to send when requesting a bank pentest proposal

Start with the application types, critical workflows, user roles, customer or tenant structure, approximate functional size and intended environment. Identify integrations and any settlement or production constraints. Explain whether source assistance is available and whether the assessment should include mobile, web and API channels. You do not need to send credentials or sensitive customer records to obtain an initial scope discussion.

Use the bank pentest brief builder to organise that context, or contact Atlant Security with your objectives and preferred timing. If an NDA is needed, use the available upload route and agree secure exchange before sending detailed architecture. The proposal should state the inputs required, the coverage approach and the evidence you will receive.

This guide was reviewed on 25 October 2026. Its matrices are practical planning recommendations, not a universal bank regulatory checklist or a promise that a fixed number of test accounts covers every architecture. Adapt the examples to the institution’s business rules and authorisation. The central principle is simple: useful test data makes security boundaries observable, and clear acceptance criteria prevent narrow observations from becoming broad claims.