Functional Analyst
A functional analyst translates business needs into precise system behavior, from fit-gap analysis to functional design. This pillar covers that craft in practice: turning a business requirement into a functional specification, running fit-gap analysis against what the system already does, mapping state machines and reason codes, and documenting behavior so nothing is left ambiguous for the build team. Written for analysts who own the spec, with examples from real banking and payments delivery.
The parts for a functional analyst joining a new team: the documentation you can and cannot trust, AI grounded on your own mapping spec, and the role guide built around a pacs.008 mapping question.
The parts aimed at functional design: business requirements refined into testable rules, diagrams read for what they do not say, and use cases with real exception flows.
The parts that touch specification work: grounding the model in your contracts and rules, then letting it draft tickets and pages under approval.
How CBPR+ replaces MT 199 queries and MT 192 recalls: camt.110 and camt.111 investigations, camt.056 and camt.029, Case Management, dates, and tests.
Regulation (EU) 2023/1113, the EU travel rule: required payer and payee data, the pacs.008 fields that carry it, missing information handling, crypto, tests.
Moving interbank MT101 to CBPR+ pain.001 under the Payment Initiation Relay rulebook: the deferred dates, MT101 to pain.001 mapping, addresses, and test cases.
MT940/950 to camt.053, MT942 to camt.052, MT900/910 to camt.054: the Nov 2027 and Nov 2028 CBPR+ dates, field mapping, reconciliation impact, and a test plan.
Payment hub architecture for analysts: channels, canonical model, validation, screening, routing to SEPA, Instant, CBPR+ and RTGS, repair queues, and booking.
SEPA Direct Debit Core and B2B for analysts: mandates, pain.008 and pacs.003, sequence types, D-1 timelines, R-transactions, reason codes, and a test matrix.
UK Faster Payments for analysts: ISO 20022 status, what replaced the NPA, Confirmation of Payee, and the PSR's APP fraud reimbursement rules as data and tests.
How analysts use AI to onboard faster: check the approved tool first, then build a glossary, grounded message explainers, session notes, and a questions list.
A 90 day onboarding plan for technical analysts in four phases: orient, map, contribute, own. What to produce each week, with a banking ISO 20022 example.
How a new analyst asks better questions: map who knows what, run first-week 1:1s, use the checked-X-think-Z format, batch questions, and keep a questions log.
How a functional analyst onboards: read the spec against the usage guideline and real messages, build a rules inventory, and ship one corrected mapping row.
How a new analyst gives useful feedback: keep an observation log, raise risk now and the rest at day 30, use evidence and SBI, and share drafts at 30%.
How an analyst runs a 90 day onboarding review: a scored self-assessment, the evidence to bring, a retrospective, and the guide you leave the next joiner.
How a new analyst reads a team's documentation: the reading order, a trust register, checking pages against code, logs, and data, and Confluence search tactics.
Every analyst career move on one map: switching in, going more or less technical, moving up, and earning more, with timelines, pay deltas, and real cases.
How employer type shapes analyst pay: banks, Big Four and boutique consultancies, outsourcers, SaaS, fintech, and public sector on pay, bonus, and security.
Realistic 2026 analyst pay by role and level in the US, Canada, UK, and Eurozone: BA, technical BA, QA, SDET, data, architecture, product, and contract rates.
Most BAs reach product manager through product owner. What changes, what it pays in four markets, the skills to add, and a six month plan with artifacts.
A business analyst career change at 40 or 50 works when you target your own domain and enter at mid band: the roles that value experience, ageism, and money.
Switching into business analysis from teaching, nursing, retail, or support: the real timeline, first-role pay by country, the pay cut, and the tech kit.
The domains that pay business analysts most in 2026, from payments and capital markets to ERP and healthcare IT: why each pays, the premium, how to break in.
What changes from junior to mid, senior, and lead business analyst: scope, trust, the artifacts that prove each level, 2026 pay bands, and a promotion case.
Less technical roles for analysts, developers, and QA: business architect, change lead, consultant. Pay in four markets, who each suits, and how to pivot.
Project manager to business analyst, or BA to PM: what each role owns, what each must learn, pay at the same level, signs of the wrong seat, and real cases.
Stripe's PaymentIntents API scored on a 12-check contract review: 22 of 24, plus the idempotency, webhook, versioning, and lifecycle findings teams must own.
How analysts use AI to draw and maintain Mermaid, BPMN, and sequence diagrams: the context pack, the house style file, the review loop, and the git workflow.
Run a requirements workshop with an AI note taker: generate the agenda from the system, drive a question bank, and diff the transcript against the spec.
How to read a diagram you were handed with AI: extract actors, flows and rules, find the missing branches, and reconcile the picture with contract and code.
A repeatable review that finds edge cases missing from your specification: nine lenses, one prompt each, run as a script before requirements are signed off.
How analysts use AI to produce real BPMN 2.0 XML, not flowchart approximations: the element subset that matters, the prompt, validation, and maintenance.
A practitioner reference for Mermaid: sequence, flowchart, state, ER, C4 context, and gantt diagrams, with copy-paste syntax and where each one renders.
What retrieval-augmented generation is, the eight stages where it fails, the requirements an analyst writes for each, and a golden-set harness that proves it.
Write business and functional requirements as YAML with stable ids, validate them with a schema, and render the BRD and FRD humans read from the same source.
A working pipeline from workshop transcript to signed UAT result for every requirement: eight stages, three machine-readable formats, and four CI gates.
Document use cases as structured data, generate Gherkin UAT scenarios from them, keep the requirement id on every scenario, and produce the sign-off pack.
Stop pasting documents into every prompt. Build a project context pack once: glossary, contracts, data dictionary, rules, examples, and retrieval for them.
The beginner's start for analysts using AI: four first wins (sharper questions, stakeholder emails, meeting follow-ups, vague tickets) and review discipline.
Turn a Teams or Zoom transcript into decisions, actions, requirements, and tickets, with consent handled, contradictions surfaced, and nothing invented.
Build a complete test plan with AI in seven steps: risk, scope, conditions, cases, data, environments, and a traceability matrix proving nothing is uncovered.
The write side of an AI connection: what to automate, what never to, the approval pattern, the dedicated account, and keeping generated tickets human owned.
How pain.001 batching works: the three-level structure, BatchBooking, how a batch becomes statement entries, and what happens when one payment fails.
How a camt.053 is structured: balance types, entries, entry details, bank transaction codes, and the references that match a statement line to a payment.
DbtrAgt, CdtrAgt, IntrmyAgt1, InstgAgt, InstdAgt: the agent fields in a pacs.008, what each one means at each hop, and which ones change in transit.
The amount fields in a pacs.008: instructed amount, interbank settlement amount, exchange rate, and the rules that decide which number the beneficiary receives.
The charge bearer codes in a pacs.008, what each one obliges every agent in the chain to do, and how ChrgsInf records who actually took what.
How the cover method works: pacs.008 to the beneficiary bank, pacs.009 COV to the correspondents, and why the two must carry identical underlying details.
Purpose code vs category purpose in ISO 20022: who reads each, the codes that change routing and treatment, and why a wrong SALA costs a payroll run.
How remittance information works in ISO 20022: the 140-character unstructured field, the structured block, ISO 11649 RF references, and remittance location.
The decision an analyst actually has to make: which payment rail fits a flow, judged on speed, finality, cost, reach, data, and what happens when it fails.
What changes when high-value payments settle in central bank money: T2's liquidity model, CHAPS enhanced data, Fedwire's cutover, and the analyst implications.
How the SEPA Credit Transfer scheme constrains ISO 20022: SLEV charges, IBAN-only, the 140-character limit, the Latin character set, and the return flows.
How SCT Inst changes payment design: a ten second end-to-end limit, 24/7/365 availability, irrevocability, and the screening and liquidity problems that follow.
How Verification of Payee works: the name and IBAN check, the four possible outcomes, what the payer sees, and the design decisions that make or break it.
How analysts review an API design before build: domain naming, state changes, money and dates, error model, pagination, idempotency, and a worked review.
A plain-language API glossary for analysts: endpoint, payload, headers, tokens, idempotency, webhooks, pagination, and more, each with a real-world example.
How to write API test cases from the contract: a six-source derivation method, 40 worked cases for one payment endpoint, and data-driven automation in Bruno.
A method for analyzing an API before integration: capability mapping, field-level data mapping, failure behavior, limits, versioning, and a fit-gap worksheet.
How to document an API as an analyst: the seven sections consumers need, an OpenAPI endpoint example, an error catalogue, flow guides, and docs you can test.
The five AI flows that measurably speed up analyst delivery: transcript to draft spec, negative test matrix, test data, log triage, and contract diffs.
Six reusable prompt patterns for requirements work: grounded extraction, format contract, adversarial review, gap interrogation, traceability, testability.
Triage is a classification problem with money attached. How to rank by business impact, settle defect versus change request fast, and defer a defect on purpose.
The output of refinement is not an estimate, it is decisions closed. What to bring, how to split a story without knowing the code, and what ready means.
Developers do not need you to read code. They need decisions, edge cases answered before they hit them, and the why behind the what. The questions that work.
QA finds where the system disagrees with the spec, and you wrote the spec. An untestable requirement is an analyst defect. How to be the partner QA needs.
ISO 20022 carries rich structured data, and every non-native hop quietly degrades it. The field-by-field loss ledger, and how to specify what you accept losing.
A field can be optional in ISO 20022, mandatory in CBPR+, forbidden by your correspondent, and absent from your database. How to build the net rule matrix.
How to build an Obsidian vault for analyst work: folder structure, atomic notes per ISO 20022 message and reason code, daily investigation logs, and Jira sync.
What user acceptance testing is, how UAT differs from SIT and QA testing, who writes the scenarios, and the entry and exit criteria that make a UAT cycle real.
The ISO 20022 payment transaction statuses explained: RCVD, ACTC, ACCP, ACSP, ACSC, PDNG, RJCT, and more, with the lifecycle order and what each guarantees.
The ISO 20022 reason codes analysts meet daily: account codes (AC01, AC04, AC06), amount codes (AM04, AM05), agent and regulatory codes, and what each means.
SWIFT, the EPC, and CHAPS deferred the November 2026 ban on unstructured addresses. What structured and hybrid addresses are and how to migrate anyway.
Which ISO 20022 message replaces each SWIFT MT: MT103 to pacs.008, MT202 to pacs.009, MT940 to camt.053, and the traps in the mapping. A reference table.
ISO 20022 gives three ways to bring money back: returns, reversals, and recalls. Who initiates each, which message carries it, and how to model them.
A business analyst describes intended behavior; a technical BA verifies it against the running system. What separates the roles and how to cross the gap.
A functional analyst is accountable for exact system behavior; a product owner for what gets built and in what order. The split, and which seat fits you.
Medallion and Data Vault answer different questions: medallion says how many quality layers, Data Vault says how to model history inside them. With diagrams.
A QA analyst derives what must be tested from requirements and risk; a test engineer builds the automation that runs it at scale. The split and the overlap.
A self-assessment matrix of 25 skills across the five technical analyst hats, with three levels per skill and where to build each one. Original to this site.
How to write acceptance criteria for AI and LLM features with non-deterministic outputs: bounds, properties, guardrails, and eval sets, not exact matches.
Business Requirements Document vs Functional Requirements Document: what each covers, who reads it, and when you need both. With worked examples.
How to turn a vague business requirement into a precise functional specification: decompose intent, define inputs and outputs, and write testable behavior.
What a data dictionary is, how to build one, and why one authoritative definition of every field prevents the ambiguity that breaks integrations and reports.
What a dead-letter queue is, why event-driven systems need one, and how an analyst specifies DLQ behavior: retries, routing, monitoring, and recovery.
Use decision tables to specify complex business rules completely: conditions, actions, rule columns, and collapsing combinations so no case is undefined.
How to write requirements for event-driven systems: event schemas, ordering, idempotency, retries, and consistency. A practitioner guide with a Kafka example.
Field notes on going from intimidated to fluent with OpenAPI: what confused me, what clicked, and how reading the contract myself changed my analyst work.
How to run a fit-gap analysis: compare requirements to system capability, classify each fit, gap, or partial, and turn gaps into decisions. Payments example.
A functional specification template: scope, actors, data, business rules, behavior, error handling, and acceptance criteria that make a spec buildable.
How to write API requirements: endpoint, method, request and response schema, status codes, error contracts, and testable acceptance criteria. With examples.
An analyst's guide to HTTP status codes: the 2xx, 4xx, and 5xx families, what each common code means, and why 202 Accepted vs 200 OK matters in payments.
What ISO 20022 actually is as an architecture: the business model, message definitions, structured data, and usage guidelines that shape modern payment systems.
How an analyst reads JSON: objects, arrays, nesting, and types. Understand API payloads, event messages, and config files without asking a developer.
How to use MoSCoW prioritization to rank requirements: what each category means, how to stop everything becoming a Must, and how it drives scope decisions.
Design negative tests systematically: boundary values, invalid inputs, state violations, and failure injection, since real defects live on the unhappy path.
A field-by-field guide to pacs.008 test cases: mandatory fields, structured data, validation, reason codes, and the pacs.002 responses that prove each case.
How ISO 20022 payment messages flow end to end: pain.001 initiation, pacs.008 interbank, pacs.002 and pain.002 status, and camt reporting, for analysts.
How an analyst reads an API contract: endpoints, methods, request and response schemas, status codes, and OpenAPI structure, without asking a developer.
How to map payment reason codes to causes and customer messages: ISO 20022 codes like AC04, internal errors, and the mapping that prevents support incidents.
How to design reconciliation between systems: matching keys, break detection, tolerance, timing, and exception handling. The control proving money is right.
The regular expressions an analyst actually needs: matching patterns in logs, validating formats like IBAN and BIC, and searching data. Practical, not theory.
What a requirements traceability matrix is, how to build one, and why it proves every requirement is designed, built, and tested. With a payments example.
How business analysts use sequence diagrams to map a flow across services, expose integration gaps, and write better requirements. With a payments example.
How to model a payment as a state machine: the states, allowed transitions, triggers, and illegal moves. The tool that makes payment status behavior precise.
Synchronous and asynchronous communication differ in whether the caller waits, and that choice shapes coupling, latency, resilience, and customer experience.
What a system context diagram is, how to draw one, and why starting at the boundary stops you scoping the wrong thing. With a payments example and the C4 model.
User stories capture intent; specifications capture exact behavior. The real difference, when each fits, and why complex systems need both. With examples.
A functional analyst turns business intent into precise, testable system behavior. What the role does in banking and payments, and how it differs from a BA.
A QA analyst proves a system behaves correctly by testing it end to end, not by reading the spec. Here is what the role does in banking and payments.
A systems analyst maps how services, messages, and data flow across a system so the pieces work as a whole. Here is what the role does in banking and payments.
A technical business analyst analyzes, codes, tests, and supports. What the role actually does day to day in banking and payments, and how to become one.
Field notes on an AI project where acceptance criteria failed: why exact-match criteria break on non-deterministic output, and what we replaced them with.
PAIN vs pacs explained: why pain.001 is not pacs.008, how pain.002 and pacs.002 mirror it, where camt fits, and how ISO 20022 splits customer and bank.
Free account
A free account, no password: an email link signs you in. It saves your steps and self-assessments on the Labs, shows your missions on a dashboard, unlocks the solutions, and, if you tick the box, sends you new missions and articles when they ship.
Your email is used to sign you in. Nothing else, unless you ask. Privacy.