Article contents
In fintech and payment services you check first everything that leads to money: login and account recovery, changes to payment details and payees, the API (the interface programs use to exchange data) behind the mobile app and partners, the logic of transfers, limits and refunds, and every place card data ends up. This work is best given to a team with hands-on experience of banking and payment systems that tests manually, understands the NBU and PCI DSS requirements and works only within an agreed scope with written permission.
Below: what attackers target, a table of "threat, example, what to check", the regulatory context in plain words with document dates, and a checklist. I also cover when it makes sense to go beyond a pentest and test the whole attack path.
In short
- Business logic means the rules of your product: limits, fees, refunds, bonuses, the order of confirmations. Attackers look for ways around these rules, and an automated scanner does not see them.
- The most expensive scenarios: account takeover, payment detail changes, API abuse and flaws in transfer logic.
- The NBU regulation for banks in Ukraine explicitly requires checking network perimeter protection with periodic penetration tests. [1]
- If a company stores, processes or transmits payment card data, PCI DSS applies to it. The current version of the standard is 4.0.1. [5] [6]
- For mature teams, a penetration test is complemented by Red Team: a controlled test of the whole attacker path to a critical target.
What attackers target in payments
Account takeover
An attacker logs into someone else's account: a password from another breach, guessing, an intercepted SMS code, weak account recovery or a session flaw. In fintech the money is available right after login, so login, password recovery and phone number changes should be the best protected parts of the product.
Payment detail changes
An attacker changes the payee's account or adds a new payee, and a second confirmation is not required or can be bypassed. In business payments this is often combined with phishing: an email from a "supplier" with a new IBAN (the payee's account number). Check whether changes need a second confirmation, whether the owner gets a notification and whether new payees have a delay.
API abuse
The mobile app, the customer portal and partners all work through the API. Typical problems: access to other people's accounts and transactions by changing a number in the request, no limits on the number of requests, too much data in responses. OWASP, an open community for application security, singles out access to other users' objects and abuse of sensitive business flows in its 2023 list of API risks. [8] [9]
Flaws in transfer logic
Examples: two simultaneous withdrawal requests both go through although there is money for only one; a refund larger than the purchase; a negative amount in a transfer; cashback credited several times for one operation. A person who understands the product finds these, not a scanner.
Card data outside the protected zone
Attackers look for places where the card number (the PAN, the full number on the card) shows up where it should not: in logs, analytics, support emails, backups. The fewer systems touch card data, the smaller the PCI DSS scope and the less there is to attack.
Threat, example, what to check
| Threat | Example | What to check |
|---|---|---|
| Account takeover | Login with a password from another breach, an intercepted SMS code | MFA (a second factor at login), attempt limits, account recovery, phone and email changes |
| Payment detail changes | A new payee or IBAN without a second confirmation | Confirmation of changes, owner notifications, a delay for new payees |
| Access to other users' data via the API | Changing an account number in a request shows someone else's transactions | Rights checks on every object, roles, partner keys |
| Mass enumeration via the API | Running through phone or card numbers | Request limits, bot protection, extra fields in responses |
| Transfer logic | Two simultaneous withdrawals, a negative amount, a repeated refund | Locking of simultaneous operations, checks of amounts and statuses |
| Card data outside the zone | Full card numbers in logs or analytics | Searching logs for card numbers, masking, boundaries of the card data zone |
| Insider access | Support staff see full card and customer data | Roles in the admin panel, an action log, least privilege |
Regulatory context in plain words
Below is only what the documents on the NBU and PCI SSC websites state directly. This is not legal advice: check with a lawyer which requirements apply to your licence, using the current version of each document.
Banks. The Regulation on information security measures in the banking system of Ukraine was approved by NBU Board resolution No. 95 of 28 September 2017 and took effect on 1 March 2018. It requires a bank to implement an information security management system in line with DSTU ISO/IEC 27001 and to check network perimeter protection with periodic penetration tests. [1]
Bank cyber protection. The Regulation on cyber protection in the banking system of Ukraine was approved by resolution No. 178 of 12 August 2022. Among the methods of an external security audit it explicitly names penetration testing. [2] Resolution No. 24 of 25 February 2025 introduced an annual bank report on information security as of 31 March. In it the bank states whether it ran a perimeter penetration test during the reporting period, who performed it and whether critical and high vulnerabilities were fixed. [3]
Payment systems. The Regulation on information protection and cyber protection in payment systems was approved by NBU resolution No. 43 of 19 May 2021. It sets requirements for information protection and cyber protection in money transfers for payment organisations, payment system participants and payment infrastructure service operators. [4]
Cards. PCI DSS means the industry standard for protecting payment card data, maintained by the PCI SSC, the Payment Card Industry Security Standards Council. It applies to those who store, process or transmit cardholder data. [5] Version 4.0.1 was published in June 2024 with no added or deleted requirements; version 4.0 was retired on 31 December 2024, and the new requirements of version 4 became mandatory on 31 March 2025. [6] The PCI SSC penetration testing guidance describes a penetration test at least once a year and after significant changes and, where the network is segmented, a check that the card data zone is really isolated from other systems. [7]
How to choose a provider with banking experience
Banking experience shows in answers to specific questions, not in logos. Ask them to describe, without client names, how the team tested online banking, payment APIs or card processing, how it worked with live systems where a mistake costs money, and what the report for the bank's security team and for the NBU looked like.
Since 2019 I have worked as a pentester on projects for banks and payment systems, and later led a cybersecurity team in the financial sector. All of it is under NDA (a confidentiality agreement), so instead of names I show anonymised sample reports and the methodology.
If you already have a security team, monitoring and regular pentests, the next step is Red Team: a test of whether your team notices a targeted attack and how fast it stops it. For most early stage fintech companies the right start is different: a manual pentest of the customer portal, the mobile app and the API.
Checklist for a fintech or payment service
Download the preparation checklist (PDF)PDF · A4
FAQ
Are there Ukrainian cybersecurity firms with experience in banking security?
Yes, and the best way to check them is with questions: who exactly will test, which banking or payment systems this person has already tested, how the team works with live systems and whether you can see an anonymised report. Client names are usually not shared because of NDAs, and that is normal.
Does a bank in Ukraine have to do penetration testing?
NBU Regulation No. 95 requires checking the bank's network perimeter protection with periodic penetration tests, and the bank's annual report to the NBU asks whether such a test was done during the reporting period. [1] [3]
Do I need PCI DSS if a payment provider handles the cards?
The standard applies to those who store, process or transmit card data, and to systems that can affect its security. If the card is entered only on the provider's page, your scope is much smaller, but not always zero. Confirm the scope with your provider and your assessor.
What should I check first in a new payment service?
Login and account recovery, payment detail changes, access rights in the API and the transfer logic. That is where a flaw turns into lost money fastest.
How is Red Team different from a pentest for fintech?
A pentest looks for as many vulnerabilities as possible in the agreed systems. Red Team checks whether an attacker can reach a specific target, such as the payment gateway, and whether your team notices. Red Team makes sense once basic pentests are routine.
References
- NBU: resolution No. 95 of 28.09.2017, Regulation on information security measures in the banking system of Ukraine (in Ukrainian) bank.gov.ua
- NBU: resolution No. 178 of 12.08.2022, Regulation on cyber protection in the banking system of Ukraine (in Ukrainian) bank.gov.ua
- NBU: resolution No. 24 of 25.02.2025, amendments on information security and cyber protection (in Ukrainian) bank.gov.ua
- NBU: resolution No. 43 of 19.05.2021, Regulation on information protection and cyber protection in payment systems (in Ukrainian) bank.gov.ua
- PCI SSC: PCI Data Security Standard pcisecuritystandards.org
- PCI SSC: Just Published: PCI DSS v4.0.1 (June 2024) blog.pcisecuritystandards.org
- PCI SSC: Penetration Testing Guidance v1.1 (2017) listings.pcisecuritystandards.org
- OWASP API Security Top 10 2023: API1 Broken Object Level Authorization api-security.owasp.org
- OWASP API Security Top 10 2023: API6 Unrestricted Access to Sensitive Business Flows api-security.owasp.org
