API security testing for IFSC banking units with fintech partners

An IFSC banking unit may give a fintech partner access to a selected set of APIs for a specific purpose, such as account verification or payments. That is how the International Financial Services Centres Authority explains partner allowlisting in its November 2026 banking FAQ. For a security test, the important question is whether the partner’s permitted purpose survives each hand-off, from the API gateway to the account or payout service.

The FAQ’s internet banking section also discusses scheduled payouts and corporate user access. It says an IBU may proceed with a scheduled payout subject to applicable verification and prescribed procedures. It leaves operation of corporate user access, including Master User access, to the bank’s policy. The checks below are practical test cases for systems that offer these features. Use the applicable circulars and your bank’s policy to establish the formal obligations and approval rules for your deployment.

Test the scope of a fintech partner’s access

Start with one partner that can verify accounts and another that can initiate payments. Write down the actions and customer accounts each one should be able to access. Then try to reuse the verification credential on a payment endpoint, substitute an account belonging to a different customer and call the same function through any older API version that is still reachable.

Capture what happens after the request passes the gateway. If an account or payment service uses its own identity to finish the operation, check whether it still enforces the original partner’s permissions. Include offboarding in the same test. Revoke the partner’s access, retry with a previously issued token and check whether the bank can see and investigate the denied request.

Follow a scheduled payout through to execution

Set up a scheduled payout using a test account and beneficiary. Change the beneficiary or amount after approval, remove the initiating user’s permissions and replay an earlier execution request. Use a separate run for each change so you can see exactly which safeguard intervened.

Agree the expected behaviour with the payments team in advance. Which changes require fresh approval? What happens to an already approved schedule when the user loses access? If a job times out after submitting a payment, can a retry submit it twice? Inspect the resulting transaction and audit record, as well as the API response.

Give the release owner evidence they can use

For each test, record the policy rule, the identity and action used, the expected decision and the actual result. A denied response is useful evidence only if the corresponding transfer or data access also failed. For an approved payout, the audit trail should let a reviewer reconstruct who set it up, what was approved and what ultimately ran.

Start with one partner that has payment access and one scheduled payout workflow. Use the resulting evidence to decide which other integrations need the same checks before release.

Source

International Financial Services Centres Authority, Frequently Asked Questions on IFSCA (Banking) Regulations, Banking Handbook and the Circulars on Internet Banking, published 5 November 2026, Section II, questions 3, 4 and 6.