Bank Pentest: Penetration Testing That Follows the Money, Not the Checklist.

A bank does not fail through its website. It fails through a service account, a trust nobody owns, or a workstation one hop from the wire room.

Our bank pentest is scoped around the six trust boundaries that actually move money: digital banking channels, payment and wire workflows, core-banking integrations, Active Directory privileged paths, vendor and MSP access, and cloud identity. Every finding is a proven attack path with its business consequence, mapped to the FFIEC, NYDFS Part 500, PCI DSS or DORA requirement your examiner will cite. Fixed price, report in 14 days, free retest.

  • Attack paths chained end to end, not a scanner export with a cover page
  • Findings mapped to the regulatory section an examiner would cite
  • Written rules of engagement: no funds moved, no downtime, a stop condition
Scope My Bank Pentest See Client Results
FFIECGLBANYDFS Part 500PCI DSS 11.4DORA Art. 25SWIFT CSP
Bank pentest: two security consultants reviewing a network diagram in a bank operations centre - Atlant Security

Senior-led testing scoped to the way a bank is actually put together: hosted core, branch network, payment operations and the suppliers between them.

200+Security Assessments
14Countries
14Days to Report
FreeRetest After Remediation
Alexander Sverdlov, founder of Atlant Security
Alexander SverdlovFounder, Atlant SecurityCISSP, CEH, CHFI, Mandiant

Leads every bank pentest personally and signs the attestation letter your examiner reads.

Connect on LinkedIn

What a Bank Pentest Actually Tests

A generic penetration test scopes by technology: one web app, one IP range. A bank pentest scopes by trust boundary, because that is how the money is protected and how it is stolen. Six boundaries cover almost every bank we have assessed.

Digital banking channels

Customer web and mobile banking: session and step-up logic, beneficiary management, payment initiation limits, and whether one customer can ever see or act on another’s account.

Payment and wire workflows

The path from an operator’s desk to a released wire or ACH file: approval separation, the jump hosts and shared drives in between, and what a compromised workstation can reach.

Core-banking integrations

The service accounts, interfaces and file transfers that connect you to your hosted core. These carry the platform’s own permissions and are where the findings that matter most tend to sit.

Internal network and Active Directory

Privileged paths from a standard workstation to domain administration, the trusts left behind by acquisitions, and the credentials cached where they should not be.

Vendor and MSP access

Remote management agents, support accounts and partner VPNs that arrive with standing privilege. A supplier compromise is a bank compromise if that access reaches the core.

Cloud and Microsoft 365

Identity, conditional access, mail rules and the storage that holds statements, loan files and board packs. Increasingly where the customer data actually lives.

Six trust boundaries, six testable questionsThe scope of a bank pentest is a list of questions an examiner would ask, not a list of hosts.Digital bankingCan one customer act on another account?Payments and wiresCan a compromised operator desk release awire?Core integrationsCan a service account be cracked and reused?Network and ADIs there a path from a teller PC to DomainAdmin?Vendor and MSPWhat does a supplier session reach?Cloud and M365Can a phished identity read the loan files?
Each boundary produces its own question for the test, and its own line in the report.

The Attack Paths That Repeat in Banks

These are not hypotheticals. They are the findings that recur across the financial-institution environments we assess, from single-charter community banks to a six-country group with 8,000 staff. Most of them are invisible to a vulnerability scanner because nothing is unpatched; the weakness is in who can reach what.

Core-platform service accounts with the original password

Accounts wired into the core-banking connection at deployment and never rotated since. Kerberoastable, and once cracked they carry the permissions of the platform itself.

A teller workstation to the wire room in one hop

A single Active Directory path from a standard branch workstation to the jump host that releases wires. It exists in most banks we assess and it is the finding boards remember.

Domain trusts from a prior acquisition

The merged institution’s domain is still trusted, still has Domain Admin-equivalent paths, and nobody currently owns it.

MSP remote-management agents under a standing Domain Admin

The vendor’s convenience becomes your largest single exposure. One compromised support session reaches everything the agent can.

Authorisation gaps in open-banking APIs

Object-level authorisation that trusts the account identifier in the request, mass assignment on beneficiaries, and payment limits enforced only in the mobile app.

Account takeover through recovery and step-up

Password reset, device re-enrolment and support-assisted recovery that lead straight to a new payee and an outbound transfer, with no cooling-off.

From a teller workstation to the wire room1Phished tellerworkstationStandard user, no local admin.Nothing on it looks valuable.2Kerberoast the coreservice accountThe password has not changedsince the platform went live.Cracked offline.3Reach the operationsjump hostThe service account is a localadmin there. One BloodHoundpath, no exploit needed.4Wire release consoleCached operator credentials.We stop here and document. Anattacker would not.
The finding boards remember: a branch workstation to a released wire without a single exploit against an unpatched system.

What the Report Has to Prove, and to Whom

A bank pentest report has two readers who want different things. The engineer wants reproduction steps and a fix. The examiner wants to see that the institution tested independently, understood the risk, and closed it. Most pentest reports serve the first reader and leave the second one to reconstruct the evidence.

Ours carries both. Every finding is mapped to the regulatory section it bears on, the executive summary states the headline numbers a board can read in two minutes, and the retest and attestation letter close the loop for the exam file.

For institutions designated under DORA there is a separate, heavier regime, TLPT for DORA, which we also deliver. For card environments the pentest is scoped to PCI DSS requirement 11.4 as well.

Mapping the report to the examREGIMEWHAT IT EXPECTSWHERE IT IS IN THE REPORTNYDFS Part 500Section 500.5: pentest inside andoutside, at least annuallyScope statement, findings register,attestationPCI DSS v4Req. 11.4: internal and external pentestevery 12 monthsSegmentation checks and CDE findingsFFIEC / GLBAIndependent testing within the securityprogrammeFindings mapped to CAT domains andSafeguardsDORAArt. 25 testing; Art. 26 TLPT fordesignated entitiesScope, method, remediation planSWIFT CSPControl 7.3A penetration testing(advisory)Secure-zone findings called outseparately
What each regime expects, and what in the deliverable answers it.
A treasury operations manager and a security consultant reviewing a payment operations workstation in a bank back office

Rules of Engagement for Live Banking Systems

Testing a bank in production is a governance exercise as much as a technical one. Before anything is touched, both sides sign rules that a risk committee can read.

  • No funds move. Payment paths are proven to the point of authorisation and documented. We never submit a transaction.
  • No availability impact. No denial-of-service techniques, agreed windows for anything that touches the core connection, and rollback steps written before use.
  • A named contact and a stop word. One escalation contact on each side, reachable throughout, and a written condition under which testing halts immediately.
  • Evidence handling. Any customer data encountered is redacted at capture, held encrypted for the engagement only, and destroyed on a documented date.
  • Vendor boundary respected. Hosted core platforms are tested at the integration surface, inside the vendor’s own testing terms.

How the Engagement Runs

Five steps, fixed price agreed at the first one, report inside fourteen days of the third.

1

Scoping call

Which boundaries matter to your charter, your core vendor and your examiner. Fixed price and timeline in writing.

2

Rules of engagement

Test windows, escalation contacts on both sides, the no-funds-movement rule for payment rails, and a written stop condition.

3

Manual testing

Senior-led, attack paths chained end to end against the agreed scope. Tools for breadth, people for the part that finds money.

4

Report and workshop

Findings register with reproduction steps, executive summary with regulatory mapping, and a live remediation session with your engineers.

5

Retest and attestation

Free retest after you fix, then an attestation letter signed by a named qualified individual, addressed to the board.

Bank Pentest Pricing

Each scope is a fixed price. Combined scopes go into one proposal with volume pricing, and you approve the total before anything starts.

ScopeWhat is coveredTestingPrice
External perimeterInternet-facing IP ranges, DNS, mail, remote access5-7 daysFrom $4,000
Open-banking and partner APIsUp to 50 endpoints, authorisation-focused5-7 daysFrom $4,000
Digital banking web application1 application, all customer and operator roles7-10 daysFrom $5,000
Internal network and Active DirectoryInternal ranges plus privileged-path analysis7-10 daysFrom $5,000
Cloud or Microsoft 365Identity, conditional access, storage, mail rules7-10 daysFrom $5,000
Mobile banking applicationiOS or Android plus its API10-14 daysFrom $6,000

Every scope includes the findings register, the executive summary with regulatory mapping, the remediation workshop, a free retest and the attestation letter. A full Active Directory assessment with examiner-ready evidence is priced separately on the AD security assessment page.

For small projects and ad-hoc work outside our pre-agreed packages or retainers, our standard hourly rate is $460.

Bank Pentest, Vulnerability Scan, or TLPT

Three different controls that get bought as if they were one. Examiners know the difference; the report has to show you do too.

What a scanner cannot tell youVulnerability scanLists known weaknesses by versionDoes not chain anythingCannot see authorisation logicCannot follow a credential across systemsSatisfies the scan requirement onlyBank pentestStarts from an examiner’s questionChains weaknesses into a proven pathTests who can act on which accountFollows service accounts to the coreSatisfies the pentest requirement, with evidence
A scan finds unpatched software. A pentest proves a path. A TLPT proves the institution under a validated scope and a twelve week clock.

Designated under DORA? The threat-led penetration test is a separate, regulator-validated exercise that runs alongside the annual pentest rather than replacing it.

Who Commissions a Bank Pentest

Community banks and credit unions preparing for an FFIEC, NCUA or state examination
Regional and multi-charter banks with acquisition-era domains and more than one core
Digital banks, neobanks and payment institutions with API-first customer channels
Institutions responding to an MRA or examiner finding on testing or privileged access
EU and UK entities meeting DORA Article 25 testing obligations ahead of a TLPT designation
Acquirers who need the target’s real security posture before the deal closes

Find Out What a Teller Workstation Can Reach

One scoping call. Bring your last pentest report, your examiner’s request, or nothing at all. You will leave with a scope written as questions, a fixed price, and a date for the report.

Scope My Bank Pentest

Book the Scoping Call

Bank Pentest FAQ

What is a bank pentest?
A bank pentest is a manual penetration test scoped around the systems that move or expose money and customer data in a bank: the digital banking web and mobile channels, the APIs behind them, payment and wire workflows, the core-banking integrations and the service accounts that run them, the internal network and Active Directory paths from ordinary workstations to privileged systems, and the vendor and MSP access that reaches all of it. The output is a set of proven attack paths with the business consequence of each, written so both your engineers and your examiner can use it.
How is a bank pentest different from a vulnerability scan?
A scan lists software with known weaknesses. A bank pentest starts from a question your examiner would ask, such as whether a compromised teller workstation can reach the wire room, and answers it by actually attempting the path, chaining weaknesses together, and stopping at the agreed boundary. Regulators treat the two as different controls: NYDFS Part 500 and PCI DSS both require penetration testing in addition to vulnerability assessment, not instead of it.
Which regulations require penetration testing for banks?
NYDFS Part 500 section 500.5 requires penetration testing of covered entities’ systems from inside and outside at least annually. PCI DSS requirement 11.4 requires external and internal penetration testing at least every twelve months and after significant changes, for any environment that stores, processes or transmits card data. The FFIEC IT Examination Handbook expects independent testing as part of the information security programme, and examiners from the OCC, FDIC, Federal Reserve and NCUA ask for it. In the EU, DORA Article 25 requires testing that includes penetration testing, and Article 26 adds threat-led penetration testing for designated entities. SWIFT CSP lists penetration testing as advisory control 7.3A.
Do you test production banking systems?
Yes, where the question requires it, under written rules of engagement agreed before anything starts. Customer-facing channels and internal networks are tested against production with defined windows, a named escalation contact on both sides, no denial-of-service techniques, and a stop condition. Payment rails are exercised in a way that never moves real funds: we prove the path to the point of authorisation and document it, we do not submit transactions.
Can a pentest touch our core banking platform?
We test the integration surface around it rather than the vendor platform itself: the service accounts that run the core connection, the interfaces and file transfers that feed it, the jump hosts and privileged paths that reach it, and the identities that can change its configuration. Those are where the bank-specific findings live. Direct testing of Fiserv, Jack Henry or FIS hosted platforms is governed by the vendor’s own testing terms, and we scope around that boundary explicitly.
Will the report satisfy an examiner or close an MRA?
The report is written for two readers at once: a technical findings register with reproduction steps and remediation for your engineers, and an executive summary with each finding mapped to the relevant FFIEC CAT domain, GLBA Safeguards section, NYDFS Part 500 section or PCI DSS requirement for the board and the examiner. After remediation we retest at no charge and issue an attestation letter signed by a named qualified individual. Independent third-party testing with documented scope, findings, remediation and retest is the standard corrective evidence for an MRA tied to testing or access controls.
How long does a bank pentest take?
Individual scopes run five to fourteen days of testing depending on size, with the report delivered within fourteen days of the start. A combined engagement covering the external perimeter, the internal network and Active Directory, and one digital banking application typically runs three to four weeks end to end, including the remediation workshop. The scoping call fixes the timeline in writing before work starts.
What does a bank pentest cost?
Scopes are priced individually and combined into one fixed proposal: external perimeter from $4,000, open-banking and partner APIs from $4,000, a digital banking web application from $5,000, internal network with Active Directory privileged-path analysis from $5,000, cloud or Microsoft 365 from $5,000, and a mobile banking app from $6,000. Every price includes the report, the remediation workshop and a free retest. Combined scopes receive volume pricing, and you approve the total before anything is touched.
Do you test open banking and partner APIs?
Yes. API testing for banks concentrates on authorisation rather than authentication: broken object-level authorisation between accounts, mass assignment on account and beneficiary objects, rate and amount limits on payment initiation, token scope and lifetime, and whether a partner’s credentials can reach data they were never granted. These are the failures that produce account-takeover and unauthorised-transfer incidents, and they are invisible to a scanner.
We are designated for TLPT under DORA. Is this the same thing?
No. A bank pentest is a scoped, weeks-long test you commission on your own terms. TLPT under DORA Articles 26 and 27 is a regulatory exercise with a control team, a scope your competent authority validates, a threat intelligence phase, at least twelve weeks of active red teaming and an attestation at the end. Most designated entities run both: the pentest on an annual cycle for the specific systems, and the TLPT every three years for the institution. We deliver both and will tell you on the first call which one your obligation actually requires.
Do you work with credit unions and community banks?
Yes, and most of our bank engagements are single-charter institutions with one or two domain controllers, a hosted core and a small IT team. The scopes are sized to that reality, the report is written for an NCUA or state examiner as much as for a large-bank audit committee, and the pricing tiers on this page are the ones those institutions actually pay.

Related Services

Penetration testing - TLPT for DORA - Active Directory security assessment - PCI DSS compliance - DORA compliance - MAS TRM - Fintech virtual CISO - bankpentest.com