PATHS / STUDY BY ROLE

Where do you want this to take you?

Each path orders the curriculum for a role and tells you how deep to go at every stop. Nothing is locked — paths are recommendations, not gates.

14 STOPS
Payments business analystThis path builds the breadth a business analyst needs: how a payment actually works, who the parties are, and how clearing and settlement differ. It then adds the flows you will most often write requirements against — the SEPA credit transfer lifecycle, its exception flows, correspondent routing choices, and the interbank message family used across modern rails. The goal is enough depth to ask precise questions, not to configure systems yourself.FOR: Business analysts who gather requirements, write user stories, and translate between product, operations, and engineering teams on payment projects.
10 STOPS
Payment operations specialistThis path follows the shape of an operations day: the lifecycle you monitor, the ledger entries behind every movement, and the reconciliation that proves the books match reality. It then goes deep on exceptions — the reject, return, and recall flows that fill your work queue — and closes with the architecture and security context around your tools. Practices vary between institutions, so treat the models here as a baseline to compare against your own shop.FOR: Operations staff who monitor payment queues, repair failed items, investigate exceptions, and reconcile accounts day to day.
11 STOPS
ISO 20022 specialistThis path takes you from why ISO 20022 exists to full working depth on the pain, pacs, and camt families, grounded in a real scheme lifecycle so the messages stay connected to actual money movement. It finishes with the cross-border usage guidelines and the translation and truncation problems that dominate real migration work. Expect to go to standards-level depth on the interbank messages.FOR: Analysts and engineers who design, map, or validate ISO 20022 messages and need authoritative depth on the model and its message families.
16 STOPS
SWIFT specialistThis path covers the SWIFT network and the full MT payments set: message structure, the customer credit transfer, bank-to-bank transfers, and the confirmations and statements that close the loop. Serial and cover routing gets standards-level attention because it shapes everything from fees to sanctions exposure. The path closes with the ISO 20022 cross-border guidelines and MT-to-MX translation, because the migration is now part of the job.FOR: Practitioners who work with SWIFT messaging daily — building, validating, or investigating MT messages and the correspondent flows they ride on.
14 STOPS
Payment solution architectThis path is built around the decisions architects actually make: which settlement model a rail uses and what that implies for liquidity, how a payment hub should be structured, and where screening sits in the flow. Message-level topics are included at working depth — enough to design interfaces honestly — with the clearing and architecture topics carrying the most weight. Designs differ widely between institutions, so the emphasis is on the trade-offs rather than one reference blueprint.FOR: Architects who design payment platforms and integrations and must reason about rails, settlement models, message interfaces, and compliance touchpoints as one system.
12 STOPS
Sanctions screening analystThis path starts with the legal foundations — what sanctions are, who imposes them, and what an asset freeze actually prohibits — because good dispositions rest on understanding what is at stake. It then covers list data and matching mechanics before finishing with investigation practice: how to work an alert from hit to documented decision. Thresholds and procedures differ between institutions, so the focus is on reasoning you can carry anywhere.FOR: Analysts who review screening alerts, investigate potential matches, and document dispositions in a compliance operations team.
16 STOPS
Screening product specialistThis path covers the full screening system rather than a single alert: list data and its delivery, matching engines and their trade-offs, message screening, and the architecture that ties them together. It closes with governance, investigation workflow, and the testing and tuning cycle, because a screening product is judged on measurable effectiveness, not feature lists. Deployment choices vary widely between institutions, so the emphasis is on the decisions and their consequences.FOR: Product managers and functional specialists who own a screening platform's capabilities, configuration, and roadmap.