Audit craft
Scoping API perimeters in payment stacks
Most API access control audits for fintech stumble in the first afternoon — not because gateways are mysterious, but because nobody agreed which surfaces sit inside the control story.
Start with money movement and customer data exposure, not with a complete microservice catalog. Interactive APIs that authorize transfers, balance reads, or mandate changes almost always belong in scope. Batch settlement jobs may sit elsewhere if change management and dual control already cover them — but only if you write that rationale down.
Three lists, not one spreadsheet
We ask cohorts to maintain in-scope, out-of-scope-with-compensating-control, and deferred lists. Deferred is not a soft “later.” It is an explicit statement that the current engagement will not cover those APIs, with a named owner and date for revisit.
Open-banking gateways in Korea often pull partner endpoints into the conversation early. Treat partner-facing interfaces as in-scope when your firm issues the tokens or hosts the policy engine. When a correspondent bank owns the auth decision entirely, document the handoff instead of inventing a control you do not operate.
What good looks like on page one
Examiners rarely ask for your entire inventory first. They ask why something was included or excluded. A one-page perimeter memo with criteria, examples, and known exceptions beats a 40-tab workbook that nobody can defend in an interview.
If you want guided practice, the perimeter module inside our Fintech API Access Control Audit course walks this exercise with a shared payment case system.