No-fluff playbooks for technical analysts.
Would you rather follow an order?
The list below is newest first. These are ordered, so you can start at part one and work up.
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.
Generate a Mermaid sequence diagram from a Bruno or Postman collection run. The trace script, the newman JSON export, the prompt, and the CI wiring.
Turn manual Kafka checks into an automated Postman collection: produce and consume over REST Proxy, poll with backoff, assert schema and ordering, and run it in CI.
Wire an assistant to Jira, Confluence, Xray, and Datadog with scoped API tokens and MCP: read safely, publish idempotently, and keep every write reviewable in git.
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.
Turn correlated Splunk or Datadog logs into an accurate Mermaid sequence diagram with AI. The queries, the export shape, the prompt, and the verification step.
Write a test strategy that makes decisions, turn conditions into an executable suite, run it in CI with Xray and Datadog, and generate the coverage proof automatically.
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.
How the whole AI analyst stack fits into a real week, the 90-day build order, what to measure, how to lead adoption on your team, and what to put on your CV.
Turn an OpenAPI contract into a Bruno or Postman collection with real assertions, generate the chaining scripts, and put the whole suite behind a CI gate.
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.
The rules of engagement for AI in a regulated delivery team: what data never leaves, how to mask it, tool tiers by blast radius, and the audit trail you keep.
Point AI at the repo and answer questions no document can: where a rule really lives, what a status actually means, what a pull request changes for the business.
Turn a Teams or Zoom transcript into decisions, actions, requirements, and tickets, with consent handled, contradictions surfaced, and nothing invented along the way.
Use AI to write the SQL you can verify, define metrics that survive scrutiny, build the dashboard nobody had time for, and automate the weekly delivery pack.
Point an AI assistant at your Obsidian vault so fourteen months of notes answer questions directly, and structure the vault so the answers are traceable and correct.
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.
Which ISO 20022 fields sanctions screening reads, why structured addresses cut false positives, and the screening defects an analyst finds in every migration.
What the Model Context Protocol is, how to connect an assistant to Jira and Confluence safely, and the six read-only questions that pay for the setup in a week.
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.
Why analysts who send, chain, and script API requests move faster: verified requirements, reproducible defects, faster triage, credible POCs, and a 30-day plan.
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 an analyst builds an API proof of concept: the decision it must settle, a two-day spike, mocks from OpenAPI, webhook proof, a scripted demo, and evidence.
Chain API requests in Bruno and Postman: capture values, pre-request and post-response scripts, token refresh, polling, branching, and a Stripe sandbox flow.
The OWASP API Security Top 10 (2023) as test cases analysts can run in Bruno or Postman: object and field authorization, auth, limits, business flows, and more.
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.
Run API test collections in CI: Bruno CLI and Newman in GitHub Actions, secrets, tags, JUnit and HTML reports, private networks, and flaky-test rules.
What counts as a breaking API change, versioning strategies, Deprecation and Sunset headers, detecting breaks with oasdiff, and consumer impact assessment.
Build a first API collection in Bruno and Postman: environments, variable precedence, inherited auth, secrets in .env or a vault, and requests imported from cURL.
GraphQL for analysts: queries, variables, mutations, errors returned with HTTP 200, cursor pagination, and hands-on testing of the GitHub GraphQL API 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.
How webhooks work and what analysts must specify: events, signatures, retries, duplicates, and ordering, plus testing with webhook.site and the Stripe CLI.
What an API is and how one works, for analysts: request and response, methods, headers, auth, status codes, and a real GitHub API call you can send today.
Troubleshoot failed API requests by symptom: connection and SSL errors, 401 vs 403, wrong-URL 404s, 415 and 422, 429, 5xx, CORS, and unresolved variables.
Small businesses now need SEO and GEO: ranking in Google and being quotable by AI answer engines. The shared technical base, what GEO adds, and how to measure.
When an AI agent beats a single prompt for analyst work, what tools it needs, where the guardrails go, and the three agent flows worth building first.
The five AI flows that measurably speed up analyst delivery: transcript to draft spec, negative test matrix, test data, log triage, and contract diffs.
Which analyst tasks to automate first, ranked by payback: environment checks, test data setup, reconciliation, contract validation, ticket evidence.
Six reusable prompt patterns for requirements work: grounded extraction, format contract, adversarial review, gap interrogation, traceability, testability.
How to build a second brain as a technical analyst: a plain-Markdown knowledge base, organized by system and decision, that answers questions months later.
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.
A go decision is made under uncertainty. The analyst's job is to make it explicit, not make it disappear. The readiness dimensions and the evidence.
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.
The difference between an API key, a personal access token, and an OAuth token, how to scope and rotate them, and where they belong across an analyst toolchain.
Use a personal access token and the Jira and Confluence REST APIs to generate traceability matrices and publish specs, with working Python scripts.
Bruno stores API collections as plain files in your repo; Postman stores them in a cloud workspace. The trade-offs, with a pacs.008 test suite in both.
A Claude Skill packages your method, references, and scripts into a folder the model loads on demand. Build one that writes pacs.008 test cases.
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.
Migration programmes scope the payment rail and forget everything reading it: screening, monitoring, the warehouse, reports. The downstream impact register.
Five identifiers travel with every payment and only one survives the whole chain. Which to trace on, reconcile on, deduplicate on, and never use as a key.
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.
Namespaces, element order, the business header, empty vs absent, amount precision, and code choices. The XML layer that fails messages your test tool accepts.
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 non-functional requirements are, the categories that matter, and how to write NFRs that are testable: measurable targets instead of adjectives. With examples.
What slowly changing dimensions are, how SCD Type 1 and Type 2 differ, how a Type 2 table works with valid_from and valid_to, and how to query it correctly.
Smoke testing proves the build is testable, sanity testing proves a fix landed, regression testing proves nothing else broke. How the three differ and when each runs.
What SQL window functions do and the three patterns analysts use daily: ROW_NUMBER for latest record per group, LAG for event timing, SUM OVER for running totals.
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.
Airflow schedules tasks; Dagster declares the data assets those tasks produce. What the task vs asset split means for lineage, testing, and debugging pipelines.
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.
Data engineers build the pipelines and platforms that move data; analytics engineers model it in the warehouse so it means something. The split, explained.
Data lineage maps how each field flows from source through transformations to the report that shows it, enabling impact analysis, trust, and audit. With a diagram.
A data mesh decentralizes data: domains own and publish their data as products, on a self-serve platform, under federated governance. Explained with a diagram.
A dbt DAG is the dependency graph of your transformations, built from ref() calls. How to read one, the staging to marts convention, and why tests live on nodes.
dbt and SQLMesh both turn SQL into tested, versioned transformation pipelines. Where they differ: SQL parsing, environments, incremental state, and lineage.
Both write code against the same systems. The backend developer owns the production system; the developer analyst uses code to verify and automate analysis.
Fivetran and Airbyte both move source data into your warehouse. They differ on openness, hosting, pricing, and who fixes the connector when the API changes.
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.
Kimball builds dimensional marts first and integrates through conformed dimensions; Inmon builds a normalized enterprise warehouse first. The classic debate, mapped.
A warehouse is a managed analytical database; a lakehouse adds warehouse guarantees to open files on object storage. The real differences, with a diagram.
Looker is a code-defined semantic layer that governs metrics; Tableau is the strongest visual exploration tool. What each optimizes for and when each fits.
The medallion architecture organizes a lakehouse into bronze (raw), silver (cleaned), and gold (business-ready) layers. What each layer owns, with a diagram.
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.
Snowflake and BigQuery are both elastic cloud warehouses. They differ on compute models, pricing units, cloud lock-in, and the knobs your team must operate.
Star and snowflake schemas differ in one thing: whether dimensions are denormalized. What each looks like, when each fits, and how to read one. With diagrams.
A systems analyst maps how systems connect and behave; a solutions architect decides how they should, and answers for it. The line, the overlap, and the jump.
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.
Both are technical; the deliverables differ. A technical BA ships verified understanding and specs; an engineer ships production code. Which seat fits you.
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.
A practitioner guide to API testing: status codes, response schemas, request chaining, authentication, error contracts, and the checks that actually catch defects.
Batch and event-driven processing differ in timing, and that difference shapes latency, failure modes, and customer experience. When to use each, with banking examples.
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 contract testing is, how it differs from integration testing, and how consumer-driven contracts catch breaking API and event changes before they reach production.
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.
The Git an analyst actually needs: clone, navigate, read a diff, browse history, and find when behavior changed. Read the codebase without breaking anything.
A walkthrough of how a technical business analyst actually investigates a failed payment: the questions, the tools, and following one transaction from the complaint to the cause.
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.
How to test idempotency in APIs and event consumers: idempotency keys, duplicate requests, redelivered events, and the race conditions that cause double processing.
The integration patterns that wire systems together: request-response, messaging, publish-subscribe, request-reply, batch file transfer, and webhooks. With payments examples.
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.
A practitioner guide to testing Kafka: consuming events in a test, asserting schema and key, verifying ordering, duplicates, and the consumer side effects that matter.
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.
A practitioner guide to payment testing: following one transaction through ingestion, events, settlement, and status, plus the rejection and stuck-payment cases that matter.
The production support skills that make a technical analyst invaluable: triage, tracing transactions, reading logs, calm under pressure, and turning incidents into requirements.
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.
Field notes from a major payments incident: how reading logs under pressure works, what the trail revealed, and the lessons about observability that became requirements.
How an analyst reads production logs to understand and debug a system: correlation ids, log levels, searching by transaction, and following one request across services.
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.
How to do regression testing in payment systems: what to retest, building a regression suite, risk-based selection, and automating the checks that protect live behavior.
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 an analyst uses Python to automate repetitive checks: calling APIs, comparing files, querying data, and chaining requests. Small scripts, large leverage.
How business analysts use sequence diagrams to map a flow across services, expose integration gaps, and write better requirements. With a payments example.
The SQL a technical analyst actually needs: SELECT, WHERE, JOIN, GROUP BY, and reading state during analysis and testing. Not for reports, for finding the truth.
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 developer analyst reads and writes enough code to verify, automate, and prototype, without becoming a full-time engineer. Here is what the role does in payments.
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.
Why testing a payment flow end to end teaches you the system and the UX better than any diagram: microservices, Kafka, the database, logs, and pain.002.