Exercise: Security Review of a Payment API

Start the review with the integration itself, so that you know exactly what you are checking. Suppose a corporate customer, a UK retailer, wants its treasury system to create SEPA payments through the bank API, with a daily limit of 1 million euros and a single payment limit of 250,000 euros. The treasury system will send payment instructions as JSON, the bank will return a pacs.008 reference and a pacs.002 status, and the customer will check balances through a separate read only API. Write down the endpoints, the data fields, the limits and the expected flow, because a reviewer who does not understand the flow cannot spot the gaps in it. Check authentication and authorisation first, because a failure here exposes everything else. Verify that the treasury system connects with mTLS using a valid certificate, that it obtains an OAuth2 token with a payment creation scope, and that the token expires within one hour. Test that a request without a token fails, that a read only token cannot create a payment, and that a token for one customer cannot access another customer account. Check that high value payments need step up approval, and that a payment of 250,000 euros to a new beneficiary needs dual approval. Record each test, the result, and the evidence, such as a log extract or a response code. Check encryption, key management and data protection next. Verify that the API uses TLS 1.2 or higher, that old TLS versions are disabled, and that the certificate is valid and issued by a trusted authority. Check that account numbers and payment details are encrypted at rest, that API keys and secrets are stored in a vault and not in source code, and that keys are rotated on a schedule. Check that the treasury system does not log full account numbers or passwords, and that test data is not mixed with production data. A single finding here, such as a secret in a configuration file, is enough to block go live until it is fixed. Check the payment controls that stop fraud and errors. Verify that each payment request carries a unique idempotency key, and that resending the same key does not create a duplicate payment of 75,000 euros. Verify that the API validates the IBAN, the BIC, the amount and the currency, and that it rejects a payment with a missing field or an amount above the limit. Verify that sanctions screening runs on every payment, that a payment to a sanctioned country is blocked, and that the system logs the screening result. Check that the API returns clear error codes, without revealing internal system details that an attacker could use. Finish the review with monitoring, logging and incident response, and then write your findings. Verify that every API call is logged with a timestamp, a user or client identity, and a payment reference, and that logs are retained for audit. Verify that alerts exist for failed authentication, for payments above a threshold, and for unusual patterns such as ten payments in one minute. Verify that the team has a runbook for a compromised token, a revoked certificate, and a suspected fraud, with named contacts and clear steps. List each finding as pass, fail or observation, with a severity and an owner, and do not recommend go live until every critical and high finding is fixed and retested.