Fintech specifics

money, payments, transactions

What should you check in calculations with money?

Precision: money can't be calculated in float: 0.1 + 0.2 ≠ 0.3. The right way is decimal or integer minor units (cents).
Rounding: which rule (up, to nearest, banker's to even) and at which step. Different steps give different sums.
Currency minor units: the hryvnia and the dollar have 2 places, the yen 0, the Bahraini dinar 3.
Splitting: 100 UAH among three is 33.33 + 33.33 + 33.34, and the sum must add up.
Display: thousands and decimal separators, the currency sign, negative amounts.

In an interview: I check that money is calculated without float, because that is where errors like zero point one plus zero point two not equalling zero point three come from. I clarify the rounding rule and the step where it happens, the number of decimal places for each currency, and that when splitting, the sum adds up to the cent.

What states does a payment have and what do you test in them?

Typically: created → processing → authorised (funds blocked) → debited → settled, with branches "declined", "cancelled", "refunded", "partially refunded".

What to test:

Every valid transition and the prohibition of invalid ones (refunding a declined payment).
The balance in each state: available and blocked.
Provider timeout: the payment doesn't disappear and isn't duplicated, and the state is clarified later.
A partial refund: the sum of refunds doesn't exceed the payment amount.
Notifications to the user in each state.

In an interview: A payment goes through states from creation to settlement, with branches of decline, cancellation and refund. I test all the valid transitions and the prohibition of invalid ones, the balance at each stage, behaviour on a provider timeout, and that the sum of partial refunds doesn't exceed the payment amount.

What are the typical risks in payment scenarios?

Double debit: a double click, a retry, the Back button.
Races: two parallel transfers from a balance that is enough for only one.
A dropped connection after sending but before the response: which state does the user see?
Limits: daily, monthly, per operation; what happens at the day boundary.
Time zones: is "today" for the limit by server time or the user's? What about an operation at 23:59?
Currencies: is the rate fixed at the moment of creation or of debit?

In an interview: The main risks are double debit, races in parallel transfers, a dropped connection in the middle of an operation, limits at the day boundary, time zones and the moment of fixing the currency rate. A double click and two tabs with the same transfer I check in every payment scenario.

What is reconciliation and how do you test it?

Reconciliation is comparing our system's data with the data of a bank or payment provider: every operation with us has a matching one at the provider, with the same amount and status.

I test: a full match; an operation exists with us but not at the provider, and vice versa; a difference in amount or status; duplicates in the provider's file. I check that discrepancies end up in a report or a queue for manual review, and don't get lost.

In an interview: Reconciliation compares our operations with the bank's or provider's data. I test not only a full match, but also discrepancies: an operation exists in only one system, different amounts or statuses, duplicates. The main thing is that every discrepancy ends up in a report for review and doesn't disappear.

What should you know about security and compliance in fintech?

PCI DSS is the standard for card data: the full number is masked (only the last 4 digits are visible), CVV isn't stored anywhere, including logs.
GDPR: personal data: minimisation, the right to deletion, consent.
KYC / AML: verifying the customer's identity and combating money laundering: restrictions before verification, suspicious operations.
Audit: every financial operation and settings change has a record of who, what, when.
SCA / 3-D Secure: confirming a payment with a code or in the bank's app.

As QA I check this at the behaviour level: that the card number is masked in the UI, API responses and logs, and that an unverified user runs into limits.

In an interview: I know the basic requirements: PCI DSS, where the card number is masked and CVV isn't stored anywhere, even in logs; GDPR for personal data; KYC and AML for customer checks; audit of all financial actions; payment confirmation through 3-D Secure. As QA I check this at the behaviour level: in the UI, in API responses and in logs.