Overview
Engagements in this sector cover payment gateways and processors, wallets and remittance platforms, lending and BNPL products, and the banking-as-a-service layers sitting between them. Testing has been delivered for payment providers in Saudi Arabia and for banking platforms covering internet banking, APIs, mobile and terminal estates in a single consolidated scope.
The work concentrates where money changes state. A payment platform has a small number of endpoints that move value and a large number that do not, and effort is weighted accordingly: every transition between pending, authorised, captured, settled, refunded and reversed is treated as an attack surface rather than a workflow step.
What drives testing in this sector
Buying triggers
- Regulatory pressure
- PCI DSS requires annual penetration testing and segmentation testing; regional regulators add their own, SAMA in Saudi Arabia, CBUAE in the UAE, the State Bank of Pakistan for institutions it licenses.
- Partner due diligence
- Acquirers, banking-as-a-service providers and card schemes ask for a current independent test report before they open the rails.
- Direct financial impact
- Unlike most sectors, a logic flaw here converts to money immediately and irreversibly.
Where the engagement concentrates
Transaction and ledger integrity
Negative amounts, decimal and rounding abuse, currency confusion, double-spend races against balance checks, and reconciliation gaps between the ledger and the processor.
Race conditions on money
Withdrawals, refunds, transfers, promo credits and limit checks tested with single-packet attacks, targeting the window where two requests both see the same balance.
KYC and onboarding bypass
Step skipping, document re-use, tier escalation without re-verification, and status fields that turn out to be client-supplied.
Authorisation across accounts and tenants
Every statement, invoice, card, beneficiary and transaction identifier replayed from a second account, including exports and support tooling.
Third-party rails and webhooks
Callback authenticity, signature verification, replay protection, and what the platform does with an unverified provider notification.
PCI DSS scope reduction
Where cardholder data flows, versus where the diagram says it flows: including logs, error reports and analytics.
Track record
Engagements delivered across banking, payments and remittance platforms: including full VAPT of an internet banking stack (web, API, Android, ATM and CDM, servers and network) and end-to-end assessments for payment providers in Saudi Arabia.
200+ projects delivered for 80+ organisations. Internal engagement log
Questions
Does a penetration test satisfy PCI DSS requirement 11.4?
An annual internal and external penetration test, plus segmentation testing where segmentation is used to reduce scope, is what requirement 11.4 asks for. Reports are written with the requirement mapping included and are structured the way QSAs expect, so the evidence can be filed without a translation step.
Can you test against production payment rails?
Testing runs against sandbox or staging rails by default. Where production testing is necessary, it is confined to accounts created for the engagement, with agreed transaction limits and a documented reversal path, arranged with your provider in advance.
How do you test for race conditions specifically?
With single-packet attacks that land parallel requests inside the same processing window, plus custom tooling written for your specific flow. Every race finding is demonstrated three times to distinguish a genuine window from timing noise.
How much does a penetration test cost for a fintech?
Cost follows scope: the number of applications and APIs, roles and tenancies, whether payment rails and webhooks are included, and the deadline. A fixed quote follows a short scoping call. Transaction logic scope costs more per hour than perimeter work and is worth more.
What do you find most often in fintech platforms?
Business logic rather than injection. Limit checks that can be raced, reversals that credit twice, transfer flows that accept a state transition out of order, and endpoints that trust an amount or account identifier supplied by the client. Nothing is malformed, which is why scanners see none of it.
Do you test KYC and onboarding flows?
Yes, and they are a recurring source of severe findings. Onboarding holds identity documents, sits before most authorisation is established, and is frequently the one flow built under deadline pressure. Testing covers document handling, verification bypass and whether an incomplete account can reach funded-account functionality.
Can you test our open banking or third-party integrations?
Yes. Aggregators and open banking connections are where trust is implicit and authorisation is often assumed, and a single gap there reaches further than the integration's size suggests. Consent flows, token scope and revocation are the parts most worth testing.
How do you avoid moving real money during testing?
Sandbox and test rails where they exist, and seeded accounts with agreed limits where they do not. Every request sent is logged, so any anomaly can be traced to the exact payload that caused it. Where a finding can only be proven on live rails, it is demonstrated once, at minimum value, with your written agreement first.