Systems Analyst
A systems analyst sees how the pieces connect, mapping end-to-end flows and documenting the integrations between services. This pillar covers that work in practice: drawing system context and sequence diagrams, choosing between synchronous and asynchronous integration, designing reconciliation between systems, and understanding ISO 20022 architecture and payment message flows end to end. Written for analysts who own the big picture, with patterns from real integration delivery.
The parts for a systems analyst joining a new team: the documentation reading order, and the role guide on mapping the landscape by following one payment and rebuilding the interface catalogue.
The system-facing parts: reading the diagram you were handed against the contract and the code, and connecting an assistant to Jira, Confluence, Xray, and Datadog.
The integration parts: connecting an assistant to Jira and Confluence over the Model Context Protocol, and the guardrails that scope what it can reach.
The observability requirements an analyst writes for a payment API: golden signals, SLOs and error budgets, log fields, metrics, alerts, and Gherkin checks.
Load test a payments API with Grafana k6 v2: write the NFR first, then scenarios, thresholds, and checks, safe idempotency keys, test types, and a CI run.
The Arazzo Specification for analysts: sourceDescriptions, steps, successCriteria, and runtime expressions, with a Stripe payment-to-refund workflow to run.
How to read and review an AsyncAPI 3.0 contract for Kafka: channels, operations, messages, bindings, keys, ordering, and schema registry compatibility.
Payments Canada for analysts: Lynx on ISO 20022, the ACSS batch system, the Real-Time Rail's Q4 2026 launch plan, RPAA supervision, and bilingual data traps.
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.
FedNow vs RTP for analysts: ISO 20022 messages, the $10 million limits, settlement, request for payment, fraud controls, and the test cases that matter.
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.
Open banking APIs for bank analysts: AIS vs PIS, the consent lifecycle, SCA, FAPI 2.0, PSD3, UK, US 1033, and Canada status, plus the test cases that matter.
What changed from OpenAPI 3.0 to 3.1 and 3.2, from nullable to type arrays, webhooks, QUERY and streaming, and what to check when a provider upgrades.
Read OpenTelemetry traces like an analyst: spans, attributes, the traceparent header, trace_id vs UETR, and finding the slow span in Jaeger, Tempo, or Datadog.
Payment hub architecture for analysts: channels, canonical model, validation, screening, routing to SEPA, Instant, CBPR+ and RTGS, repair queues, and booking.
How to specify an MCP server for your own API: which operations become tools, schemas, OAuth scopes, approval for writes, audit, injection risk, and tests.
How the SWIFT gpi Tracker works for analysts: the UETR, ACSP with G000 to G004, ACCC and RJCT, the update channels and API, Stop and Recall, and what to test.
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.
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.
Developer analyst onboarding: week one access, reading the repo with AI, tracing a pain.001 by its identifiers through logs and SQL, and a root cause note.
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.
Systems analyst onboarding: follow one payment across channel, hub, screening, gateway, and ledger, then build the context diagram and interface catalogue.
Restarting an analyst career in Canada, the UK, the EU, or the US: why the first role is often a level down, how local proof wins it back, and pay per market.
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.
Head of business analysis or principal analyst? What each does all day, pay in four markets, how to trial management, and how to create a principal track.
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.
How analysts become analytics engineers: dbt, SQL, Git, tests, and modelling in 6 to 12 months, realistic 2026 pay in four markets, and a portfolio spec.
Technical analyst to forward deployed engineer, solutions engineer, or implementation consultant: what each does, 2026 pay, skills that transfer, and the gap.
Senior systems analyst to solutions architect pays 15 to 25 percent more, usually after 8 to 12 years. The ADRs, NFRs, cloud cert, and design reviews it takes.
How to move from operations, production support, or the service desk into a business analyst or technical BA role: what transfers, the plan, and real pay.
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.
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.
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 Postman CLI or newman JSON export, the prompt, and CI wiring.
Turn manual Kafka checks into an automated Postman collection: produce and consume over REST Proxy, poll with backoff, assert schema and ordering, run in CI.
Wire an assistant to Jira, Confluence, Xray, and Datadog with scoped tokens and MCP: read safely, publish idempotently, 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 writes for each, and a golden-set harness that proves it.
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 coverage proof.
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.
Stop pasting documents into every prompt. Build a project context pack once: glossary, contracts, data dictionary, rules, examples, and retrieval for them.
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 what no document can: where a rule really lives, what a status actually means, what a pull request changes for the business.
How pain.001 batching works: the three-level structure, BatchBooking, how a batch becomes statement entries, and what happens when one payment fails.
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.
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.
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.
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.
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 cURL imports.
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.
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.
Which analyst tasks to automate first, ranked by payback: environment checks, test data setup, reconciliation, contract validation, ticket evidence.
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.
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 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.
Bruno keeps API collections as files in your repo with no account; Postman wraps them in a cloud platform, now with Native Git. Trade-offs for pacs.008 tests.
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.
What non-functional requirements are, the categories that matter, and how to write testable NFRs with 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.
The ISO 20022 payment transaction statuses explained: RCVD, ACTC, ACCP, ACSP, ACSC, PDNG, RJCT, and more, with the lifecycle order and what each guarantees.
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.
Airflow schedules tasks; Dagster declares the data assets those tasks produce. What the task vs asset split means for lineage, testing, and debugging pipelines.
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.
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 transformations, built from ref() calls. How to read one, the staging to marts convention, and why tests sit 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.
Kimball builds dimensional marts first and integrates through conformed dimensions; Inmon builds a normalized enterprise warehouse first. The 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.
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.
Batch and event-driven processing differ in timing, which shapes latency, failure modes, and customer experience. When to use each, with banking examples.
What contract testing is, how it differs from integration testing, and how consumer-driven contracts catch breaking API and event changes before production.
What a dead-letter queue is, why event-driven systems need one, and how an analyst specifies DLQ behavior: retries, routing, monitoring, and recovery.
How to write requirements for event-driven systems: event schemas, ordering, idempotency, retries, and consistency. A practitioner guide with a Kafka example.
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.
How a technical business analyst investigates a failed payment: the questions, the tools, and following one transaction from the complaint to the root cause.
How to test idempotency in APIs and event consumers: idempotency keys, duplicate requests, redelivered events, and race conditions behind double processing.
Integration patterns that wire systems: request-response, messaging, publish-subscribe, request-reply, batch file transfer, and webhooks. 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.
A guide to testing Kafka: consuming events in a test, asserting schema and key, verifying ordering and duplicates, and checking consumer side effects.
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.
A practitioner guide to payment testing: one transaction through ingestion, events, settlement, and status, plus the rejection and stuck-payment cases.
Production support skills for technical analysts: triage, tracing transactions, reading logs, staying calm, and turning incidents into requirements.
Field notes from a major payments incident: reading logs under pressure, what the trail revealed, and the observability lessons that became requirements.
How an analyst reads production logs to debug a system: correlation ids, log levels, searching by transaction, and following one request across services.
How to design reconciliation between systems: matching keys, break detection, tolerance, timing, and exception handling. The control proving money is right.
Regression testing in payment systems: what to retest, building a regression suite, risk-based selection, and automating checks that protect live behavior.
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.
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.
A developer analyst reads and writes enough code to verify, automate, and prototype without becoming a full-time engineer. What the role does in 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.
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.
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.