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 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.
Stripe's PaymentIntents API scored on a 12-check contract review: 22 of 24, plus the idempotency, webhook, versioning, and lifecycle findings your team 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.
How to 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 current spec.
How to read a diagram you were handed with AI: extract actors, flows and rules, find the missing branches, and reconcile the picture against the contract and the code.
A repeatable review that finds the edge cases missing from your specification: nine lenses, one prompt each, run as a script before the 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 must write for each, and a golden-set harness that proves it works.
Write business and functional requirements as structured YAML with stable ids, validate them with a schema, and render the BRD and FRD humans read from the same source.
A working pipeline that carries a requirement from a workshop transcript to a signed UAT result: eight stages, three machine-readable formats, and four CI gates.
Document use cases as structured data, generate UAT scenarios in Gherkin from them, keep the requirement id on every scenario, and produce a sign-off pack automatically.
Stop pasting documents into every prompt. Build a project context pack once: glossary, contracts, data dictionary, rules, examples, and the retrieval that finds them.
The beginner's start for analysts using AI: four first wins (sharper questions, stakeholder emails, meeting follow-ups, vague tickets) and the review discipline.
Turn a Teams or Zoom transcript into decisions, actions, requirements, and tickets, with consent handled, contradictions surfaced, and nothing invented along the way.
Build a complete test plan with AI in seven steps: risk, scope, conditions, cases, data, environments, and a traceability matrix that proves nothing is uncovered.
The write side of an AI connection: what to automate, what never to, the approval pattern, the dedicated account, and how to keep generated tickets owned by a human.
How pain.001 batching works: the three-level structure, BatchBooking, how a batch becomes entries on a statement, and what happens when one payment in a file fails.
How a camt.053 is structured: balance types, entries, entry details, bank transaction codes, and the references that let you 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, with the action each implies.
CBPR+ ends fully unstructured addresses in November 2026. What structured and hybrid addresses are, the elements that matter, and how to migrate without rejections.
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.
When money must come back, ISO 20022 gives three distinct mechanisms: 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 when outputs are non-deterministic. Use bounds, properties, guardrails, and evaluation sets, not exact matches.
The difference between a Business Requirements Document and a Functional Requirements Document: what each covers, who reads it, and when you need both. With examples.
How to turn a vague business requirement into a precise functional specification: decompose intent, define inputs and outputs, and write testable behavior. With examples.
What a data dictionary is, how to build one, and why a single 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. With examples.
How to use decision tables to specify complex business rules completely: conditions, actions, rule columns, and collapsing combinations. The tool that leaves no case 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 how I work as an analyst.
How to run a fit-gap analysis: compare requirements against system capability, classify each as fit, gap, or partial, and turn gaps into decisions. With a payments example.
A practical functional specification template: scope, actors, data, business rules, behavior, error handling, and acceptance criteria. The structure that makes a spec buildable.
Write API requirements the right way: 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 vs 200 matters in payments. Practical, not exhaustive.
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 without asking a developer. Practical, not theory.
How to use MoSCoW prioritization to rank requirements: what each category means, how to apply it without everything becoming a Must, and how it drives scope decisions.
How to design negative tests systematically: boundary values, invalid inputs, state violations, and failure injection. The unhappy path is where the real defects live.
A field-by-field guide to writing pacs.008 test cases: mandatory fields, structured data, validation, reason codes, and the pacs.002 responses that prove each case.
How payment messages flow end to end in ISO 20022: pain.001 initiation, pacs.008 interbank, pacs.002 and pain.002 status, and camt reporting. A systems analyst map.
How an analyst reads an API contract: endpoints, methods, request and response schemas, status codes, and OpenAPI structure. Understand any API 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 that proves the money is right.
The regular expressions an analyst actually needs: matching patterns in logs, validating formats like IBAN and BIC, and searching data. Practical regex, 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: define the states, the allowed transitions, the triggers, and the illegal moves. The tool that makes status behavior precise.
Synchronous and asynchronous communication differ in whether the caller waits, and that choice shapes coupling, latency, resilience, and the 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. Here is 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. Here is 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. Here is what the role actually does day to day in banking and payments, and how to become one.
Field notes on an AI project where the acceptance criteria did not work: 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.