For payment service providers, neobanks, lenders, wallets, card issuers and the platforms that embed them
For payment providers, lenders, wallets and card programmes we test the flows that move or release funds: onboarding and identity checks, payment initiation, refunds and payouts, ledger consistency under concurrent requests, and the back-office tools that can override all of them.
An attacker inside a payment platform wants one of three things: to move money, to borrow an identity that can move money, or to take the customer data that makes both easier. The stolen funds are rarely the largest cost. Card schemes can pass fines down through your acquirer, a partner bank can suspend a programme, supervisors ask how a control failed and why nobody noticed, and a fintech that depends on a sponsor bank can lose the relationship it is built on. The damage we look for is usually quiet: a refund endpoint that trusts the amount in the request, a support console that changes a payout account without a second approval, a reconciliation job that only runs overnight.
An endpoint checks who the caller is but not whether the account, card or transfer named in the request belongs to them. With sequential or guessable identifiers, one missing check exposes every customer's balances and statements. OWASP ranks broken object level authorisation first in its API Security Top 10 for 2023.
Passwords leaked from other services are replayed against your login and reset flows, and where SMS is the second factor, a SIM swap moves the one-time code to the attacker's phone. The question a test answers is what an attacker can do in the minutes after login: add a payee, change the phone number, raise a limit or cash out before any alert fires.
An attacker who controls or convincingly spoofs a supplier's or customer's mailbox asks for bank details to change just before a large payment. In fintech the same approach targets operations staff who can update payout accounts or approve manual transfers. The defence is as much procedure as technology: call-back verification on a known number and dual approval for any change to where money goes.
Logic flaws let an attacker refund more than was paid, refund one payment twice with parallel requests, or withdraw a balance that a pending transaction has already spent. Scanners do not find these. Finding them takes someone who reads the money flow and sends requests in an order the developers did not expect.
Criminals holding stolen card numbers use checkout, wallet top-up and card-linking endpoints to learn which cards still work, spreading small attempts across many accounts and addresses. You pay in chargebacks, processor fees and scheme attention. The fix is velocity rules and rate limits that treat these endpoints as a fraud surface.
Consoles that show full identity documents, impersonate a customer or edit a ledger entry are worth as much to an attacker as production credentials, yet they are often protected by one single sign-on session and thin logging. We test them the way an attacker who has phished one support agent would use them.
If you store, process or transmit card data, PCI DSS 4.0.1 requirement 11.4 asks for internal and external penetration tests at least once every 12 months and after significant change, and service providers that rely on segmentation must test it every six months. DORA has applied to EU financial entities since 17 January 2025, and those their supervisor designates must also run threat-led penetration tests at least every three years. NYDFS Part 500 expects an annual penetration test from inside and outside the network boundary, and notice to the Department within 72 hours of determining that a cybersecurity incident occurred. Israeli banking corporations have worked under Bank of Israel Directive 364 since 18 May 2026: it replaced Directives 357, 361 and 363, requires a systematic testing programme in which a sufficient share of security controls is tested at least once a year and every control at least once every three years, and names penetration tests and red team exercises among the test types. AI systems that assess the creditworthiness of individuals are high-risk under the EU AI Act; systems used to detect financial fraud are excepted.
The scoping call settles which of these apply to your systems.
Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.
Duration: 5 to 10 working days
iOS and Android testing of the binary, on-device storage and transport, and of the backend API the app calls, replaying the app's own tokens to check whether one user can read another's data. On the device we check what the keychain or keystore stores, whether certificate pinning survives a bypass attempt and what deep links can trigger.
Duration: 6 to 10 working days
A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.
Duration: 5 to 15 working days, depending on codebase size
An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.
Duration: 4 to 8 working days
Phishing, vishing and physical pretexting run against your staff, help desk and finance team, only under written authorisation that names the targets, pretexts and limits. Results are reported by channel and pretext, never by name: how far a convincing approach got, how many people reported it and how long the first report took to reach someone who acted.
Duration: 2 to 4 weeks including campaign preparation
Objective-based adversary simulation: we agree the objectives, try to reach them over several weeks and measure what your detection and response do along the way. Purple mode runs the same scenarios with your defenders in the room, tuning detection as each technique is replayed.
Duration: 3 to 6 weeks
Closest written-up engagement
Fintech · Under two weeks
Investors wanted proof the payment flows were sound. Internal QA had never tested adversarially.
It is written to. The report states the scope, dates, methodology, tester qualifications and the retest status of each finding, which is what an assessor looks for under requirement 11.4. Tell us on the scoping call where your cardholder data environment begins and ends; if segmentation keeps systems out of scope, testing that segmentation is part of the work. The quarterly external scans in requirement 11.3.2 are a separate exercise and must come from a PCI SSC Approved Scanning Vendor.
Usually, yes. Test accounts, low-value instruments and the actions that are off-limits are agreed in the rules of engagement, and all our traffic carries an identifier your monitoring can filter on. Where a test would trigger a real transfer, a real card authorisation or a regulatory report, we prove the flaw in a sandbox or staging environment and confirm only the precondition in production, with your sign-off.
Most of the testing questions, yes. Bank and enterprise questionnaires usually ask for an independent penetration test from the last 12 months, its scope, open findings by severity and a remediation date for each. The report and the attestation letter answer those directly, and the free retest of every fixed finding within 30 days of report delivery means you can send an updated letter once the critical and high findings are fixed.
Where they sit in the same flow, yes. Velocity limits on card linking, step-up rules before a payee change and holds on new payout accounts are probed the way an attacker would probe them, and every gap is reported as a finding with its business impact spelled out.
We pick the checks that apply to your systems and the frameworks you answer to. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.