Onboarding as a Systems Analyst: Map the Landscape by Following One Payment

A systems analyst onboards fastest by following one real payment through every system it touches and drawing the map as they go. The first deliverable is a current-state context diagram plus an interface catalogue, with producers, consumers, message types, transports, owners, service levels, and monitoring for each arrow, and the unknowns named rather than guessed.

The integration architecture team I joined had just lived through two of the biggest changes in payments messaging in a decade. The Fedwire Funds Service had moved to ISO 20022 in its single-day cutover on 14 July 2025, and the SWIFT coexistence period for cross-border payment instructions under CBPR+ had ended in November 2025, so MT103 was gone from correspondent traffic and pacs.008 was the only language spoken. Both migrations had shipped. Both had been run as programmes with their own architects, their own diagrams, and their own Confluence spaces. And when the programmes closed, the people went back to their day jobs and the diagrams stopped being updated.

On my second day, the head of the team asked me to “own the interface catalogue.” It was a spreadsheet with 140 rows, last edited eleven months earlier. A third of the rows still said MT103 in the message type column. Nobody trusted it, so nobody used it, so nobody updated it.

This is part 10 of The First 90 Days, the systems analyst angle, and it is how I turned that spreadsheet into the document the team reaches for during incidents. If you want the general plan that every role shares, start with part 1. The developer analyst angle in part 9 goes deep into one system; this one goes wide across all of them.

Why follow one payment instead of reading the architecture?

Because architecture documents describe the landscape as it was designed, and a payment shows you the landscape as it is.

In my first week I had access to three sources of truth that disagreed with each other: the migration programme’s target-state diagram, the interface catalogue spreadsheet, and what the systems actually did. The target state showed the payment hub calling sanctions screening synchronously. The catalogue showed a queue between them. The logs showed both: a synchronous call for real-time screening, and a separate asynchronous queue for payments that went to manual review. Neither document was wrong, exactly. Each described one path and left out the other.

A single real payment cuts through that. It took one route, on one day, with timestamps at every hop. You cannot argue with it.

Pick it carefully. I use three criteria:

1. Cross-border, outbound, settled. A pacs.008 under CBPR+ touches the most systems: channel, hub, screening, fraud, the SWIFT gateway, the correspondent, the ledger, notifications, and reconciliation. A domestic instant payment skips half of them.
2. Recent, but not today. A week old, so every downstream step has completed, including the end-of-day statement and the next morning’s reconciliation.
3. Boring. No repair, no return, no investigation. You want the happy path first. The exceptions come in week four, once you know what normal looks like.

I asked the payments operations lead for “one ordinary outbound cross-border customer payment from last Tuesday, any currency, no exceptions,” and got a UETR in a chat message within ten minutes. That UETR was my onboarding.

How do you trace a payment across every system?

Hop by hop, writing down four things at each one: the system, the timestamp, the identifier that system uses, and the message or call that moved the payment to the next hop. When the identifier changes, you also write down what links the old one to the new one, because that link is where tracing breaks during incidents.

Here is the trace I built over my first two weeks, simplified:

Hop	System	Identifier used here	Message or call out	Sync or async
1	Corporate channel (host-to-host)	File name, MsgId, EndToEndId	pain.001 into the payment hub	Async (file drop)
2	Payment hub	Internal payment id; UETR generated here	Screening request	Sync (REST)
3	Sanctions screening	Screening case id, payment id	Pass or hold response	Sync, with async fallback queue for holds
4	Fraud scoring	Payment id	Score response	Sync (REST, 300 ms budget)
5	Payment hub	Payment id, UETR	Debit posting request to core ledger	Sync (MQ request and reply)
6	Core ledger	Ledger transaction reference	Posting confirmation	Sync (MQ reply)
7	SWIFT gateway	UETR, MsgId	pacs.008 to correspondent	Async (MQ to gateway, then SWIFT network)
8	Correspondent and SWIFT gpi	UETR	pacs.002 and gpi tracker updates back	Async
9	Notifications	Ledger reference	camt.054 debit notification to corporate	Async (Kafka, then channel)
10	Statements	Ledger reference	camt.053 end-of-day statement	Batch (nightly)
11	Reconciliation	Ledger reference, nostro statement reference	Match against correspondent’s camt.053	Batch (next morning)

Look at the identifier column. The UETR is generated at hop 2, travels to the gateway and the network at hops 7 and 8, and then disappears at hop 6. The core ledger stores its own transaction reference and nothing else. Every system downstream of the ledger, notifications, statements, reconciliation, knows the payment only by the ledger reference.

That single observation became my first real finding, and it is the most common one I have seen in banks: the UETR is mandatory on the wire and absent in the books. When a corporate client calls asking “where is my payment, here is the UETR from the gpi tracker,” the operations team has to go to the payment hub to translate it to a ledger reference before they can look at the statement. It works, but it is a manual hop, and during the November 2025 cutover weekend it was exactly the hop that queued up.

For a deeper walk through how these messages chain across a bank, see payment message flows, and for the layered view of where ISO 20022 sits in each system, ISO 20022 architecture.

How do you find each hop when you do not know the systems yet?

You ask the owner of the previous hop “where does it go next, and what does it call it there?” Every team knows their outbound interface, even if they know nothing beyond it. The payment hub team told me the gateway queue name. The gateway team told me which correspondent. The ledger team told me the posting reference format. Eleven short conversations, each one a single question with a UETR or a reference attached, and each one also introduced me to a team I would need again.

That is the systems analyst version of part 4, asking the right questions: one question, one identifier, one owner. Nobody turns down a question that comes with the exact reference they need to answer it.

Where the logs were readable, I drew the sequence from them directly, which is the method in sequence diagrams from logs.

How do you draw the context diagram as you go?

Start it on day one with only the system you are sure of, the payment hub, and add one box and one arrow for every hop you verify. Never draw an arrow you have not seen evidence for. A context diagram that grows from evidence is slower to draw and faster to trust.

I keep mine as Mermaid in a Git repository, so changes are reviewable and the diagram renders in Confluence and in the repository viewer. After week two, the payment’s path looked like this:

sequenceDiagram
    autonumber
    participant CH as Corporate channel
    participant PH as Payment hub
    participant SS as Sanctions screening
    participant FR as Fraud scoring
    participant CL as Core ledger
    participant GW as SWIFT gateway
    participant CB as Correspondent
    participant NT as Notifications
    participant ST as Statements and recon

    CH->>PH: pain.001 (file drop, async)
    PH->>SS: screen payment (REST, sync)
    SS->>PH: pass
    PH->>FR: score payment (REST, sync)
    FR->>PH: score below threshold
    PH->>CL: debit posting (MQ request)
    CL->>PH: posted, ledger ref (MQ reply)
    PH->>GW: pacs.008 with UETR (MQ, async)
    GW->>CB: pacs.008 over SWIFT
    CB->>GW: pacs.002 ACSC
    CL->>NT: posting event, ledger ref only (Kafka)
    NT->>CH: camt.054 debit notification
    CL->>ST: end of day postings (batch)
    Note over CL,ST: UETR not carried past the ledger

The Note line is the most important line in the diagram. A context diagram that only shows boxes and arrows tells you what talks to what. Annotating where identifiers are lost, where calls are synchronous, and where batches run tells you where things break, which is what the diagram is for.

For the full method of drawing one that a whole programme can use, including how to choose the boundary, see the system context diagram. For why the synchronous and asynchronous distinction on each arrow matters so much in payments, see synchronous vs asynchronous.

What goes in an interface catalogue?

Nine columns. Fewer and it cannot support impact analysis; more and nobody maintains it.

Column	Example	Why it matters
Interface id	INT-PH-GW-01	Permanent; referenced from tickets, incidents, and changes
Producer	Payment hub	Who sends
Consumer	SWIFT gateway	Who receives
Message type	pacs.008 (CBPR+)	What the business meaning is
Transport	IBM MQ, queue PH.GW.OUT	How it physically moves, and where to look when it stops
Format and version	XML, pacs.008.001.08, CBPR+ usage guideline	What changes when the standard releases
Owner	Payments integration team	Who changes it and who is paged
Service level	Within 60 seconds of ledger posting, 07:00 to 18:00	What “late” means
Monitoring	Queue depth alert above 500, dashboard link	How you know it failed before the customer does

I rebuilt the team’s catalogue from the trace, not from the old spreadsheet. Every interface the payment touched got a row, verified with the owning team. Then I went through the old 140 rows and marked each one as verified, stale (exists but details wrong), retired (the MT103 rows, mostly), or unknown. The first pass took three weeks. At the end, 61 rows were verified, 38 were retired, and the rest were stale or unknown with an owner to ask.

The retired rows were a finding in themselves. Several MT103 interfaces were still configured in the gateway, receiving nothing since November 2025, but still listed in the monitoring as “no traffic: OK.” An interface nobody uses that still has an open port and a queue is an audit finding waiting to happen, and the security team was glad to have the list.

Two rows from the rebuilt catalogue:

- id: INT-PH-GW-01
  producer: payment-hub
  consumer: swift-gateway
  message: pacs.008
  guideline: CBPR+ (SR2025)
  transport: { kind: ibm-mq, queue: PH.GW.OUT }
  format: { encoding: xml, version: pacs.008.001.08 }
  owner: payments-integration
  sla: "within 60s of ledger posting, 07:00 to 18:00 local"
  monitoring: "queue depth > 500 alerts on-call; dashboard PAY-GW"
  carries_uetr: true
  status: verified
  verified_on: 2026-09-18

- id: INT-CL-NT-02
  producer: core-ledger
  consumer: notifications
  message: posting-event (internal)
  transport: { kind: kafka, topic: ledger.postings.v3 }
  format: { encoding: json, version: v3 }
  owner: UNKNOWN
  sla: UNKNOWN
  monitoring: "consumer lag dashboard exists, no alert"
  carries_uetr: false
  status: unknown

The carries_uetr field is not in most catalogue templates, and I added it because the trace showed it mattered. That is the right instinct for a systems analyst: let the evidence decide the columns, not a template. In a card-heavy landscape the equivalent might be whether the interface carries the network transaction id; in an instant payments landscape, whether it carries the scheme’s timeout timestamp.

If the transport types in that table are unfamiliar, integration patterns explains request and reply over MQ, publish and subscribe on Kafka, and file transfer, and when each one is the right choice.

Which three questions do you ask about every arrow?

For each arrow on the diagram and each row in the catalogue:

1. Is it synchronous or asynchronous? If synchronous, what is the timeout, and what does the caller do when it fires? If asynchronous, what happens to a message that cannot be processed: is there a dead letter queue, and does anyone look at it?
2. Which identifier crosses it? UETR, EndToEndId, MsgId, an internal id? If the identifier changes here, where is the mapping stored, and can operations query it?
3. Who is paged when it stops? Not who owns the code. Who gets the alert at 02:00. If the answer is “nobody,” that is a finding.

The third question produced my second finding. The Kafka topic from the core ledger to notifications had a consumer lag dashboard but no alert. If the notifications consumer stopped, the camt.054 debit notifications to corporate clients would silently stop, and the first signal would be a treasurer asking why they had not received confirmations. The fix was a single alert rule, the kind of change that takes an afternoon and prevents a very bad Monday.

Sanctions screening deserves its own pass on question one, because it is the hop where synchronous and asynchronous paths split by design: the real-time pass path and the hold path for manual review behave completely differently. ISO 20022 sanctions screening covers what the richer ISO data changed for screening, and why the hold path is where most latency incidents start.

What is a systems analyst’s first deliverable?

A current-state context diagram plus the interface catalogue, with three named unknowns. Not a complete-looking diagram. A diagram that is accurate where it is drawn and explicit where it is not.

I presented mine at the end of week five, in a thirty-minute slot at the architecture forum. The structure:

1. The trace. One payment, eleven hops, timestamps. Two minutes. It grounds everything else in fact.
2. The diagram. Current state, verified from evidence, with sync and async marked and the UETR boundary annotated.
3. The catalogue. 61 verified interfaces, 38 retired, the rest classified with owners to ask.
4. Three unknowns, each with a named owner and a proposed date:
   • Who owns the ledger-to-notifications Kafka topic, and what is its service level? (Ledger platform lead, by end of month.)
   • Does the correspondent’s camt.053, which reconciliation matches against, carry the UETR in the transaction references, and if so, could reconciliation match on it instead of the amount and value date? (Nostro reconciliation lead.)
   • Are the remaining MT103 gateway interfaces safe to decommission? (Gateway owner, with security.)
5. Two findings with fixes: the missing alert on the notifications topic, and the UETR loss at the ledger, framed as a question for the target state rather than a defect.

That last framing matters for a new person. The UETR loss at the ledger was a design decision made years before I arrived, by people who were in the room. Presenting it as “here is where the identifier stops, and here is the operational cost I measured” lets the architects own the next step. Part 5, giving feedback as a new analyst, is about exactly that distinction between an observation and an accusation.

The second unknown, about reconciliation, is worth a word. Most reconciliation engines in banks still match nostro entries on amount, currency, value date, and a reference that has been through several transformations. If the correspondent’s statement carries the UETR, matching on it removes a whole class of false breaks. Reconciliation design covers matching keys, and the camt.053 bank statement explains where the references sit in the statement entries.

How do the five onboarding levers apply to a systems analyst?

AI. Use it to transcribe and compare, not to imagine the landscape. Paste a target-state diagram image into an approved assistant and ask for a list of every box and arrow as structured data, then diff that list against your verified catalogue. The differences are your question list. Never ask it to “describe a typical bank payments architecture” and treat the answer as yours. Part 3 covers the knowledge pack this feeds.

Documentation. Programme documentation is the least reliable kind in a bank, because it freezes at go-live. Migration target states, cutover runbooks, and interface specifications from the ISO 20022 programmes are excellent for intent and dangerous for fact. Part 2 explains how to rate each source before you rely on it.

Questions. One identifier, one hop, one owner. “This UETR left your system at 10:42:07 on queue PH.GW.OUT. What does the gateway call it, and where does it go next?” is answerable in a minute by the right person.

Feedback. Your first feedback is about things that have no owner: the topic without an alert, the queue nobody watches, the interface nobody decommissioned. These are rarely political, because nobody is defending them.

First deliverable. The diagram and catalogue above. Choose it because it is used by everyone, from incident managers to auditors to the next migration programme, which means it earns you introductions across the whole bank.

A 90-day plan for a systems analyst

Weeks	Focus	Output you can show
1	Pick one payment; access to logs and message viewer; meet the payment hub team	The payment’s UETR and the first three hops verified
2	Finish the trace, one owner per hop	Eleven-hop trace table with identifiers and timestamps
3	Context diagram from evidence	Mermaid diagram in the repository, sync and async marked, identifier boundaries annotated
4	Exceptions	Same trace for a returned payment (pacs.004) and a screening hold
5	First deliverable	Diagram plus catalogue presented, three unknowns with owners
6 to 7	Inbound flows	Trace an incoming pacs.008 to credit posting and camt.054, add rows to the catalogue
8 to 9	Batch and reporting edges	Statements, reconciliation, regulatory reporting interfaces catalogued
10 to 11	Change readiness	Impact analysis for the next known change, such as the November 2026 CBPR+ structured address requirement, using the catalogue
12 to 13	Hand-off and review	Catalogue owner process agreed; 90-day review

Week 10 is where the catalogue proves its worth. The CBPR+ requirement that cross-border payments carry structured or hybrid addresses from November 2026 touches every interface that carries a party address. With a verified catalogue, the impact analysis is a filter on the message type column plus a conversation with each owner. Without one, it is a month of discovery.

What does “onboarded” look like for a systems analyst at day 90?

1. You can draw the payment landscape from memory, with transports and identifiers, and it matches the evidence.
2. Given any interface, you can name its owner, its service level, and how its failure is detected, or you know exactly who to ask.
3. The catalogue is used during incidents, and incident managers update it when they discover something it got wrong.
4. You can produce a first-cut impact analysis for a message change in a day, because the catalogue tells you every producer and consumer of that message type.
5. Architects bring you their target-state diagrams to check against reality. That is the moment the role has landed.

Practise mapping a system you have never seen

If you want to rehearse this before your next start date, Northline Pay is the fictional payments platform behind the Labs: a merchant API, a Kafka event backbone, a ledger, and a webhook dispatcher, with the contract, the event catalogue, and the database schema published. Try building its context diagram and interface catalogue from the artifacts alone, then check yourself against the missions. It is a small landscape, which is exactly right for practising the method.

The takeaway

Systems analyst onboarding is one payment followed through every system it touches, with the system, timestamp, identifier, and outbound message written down at each hop. From that trace you draw the context diagram, marking synchronous and asynchronous arrows and annotating where identifiers like the UETR are lost. From the diagram you build an interface catalogue with nine columns, owners and monitoring included. Your first deliverable is the current state with three named unknowns, not a complete-looking guess, and by day 90 the catalogue should be the document the team opens during an incident.

The domain knowledge behind this, how payments, core systems, and correspondent banking actually fit together, is what makes the trace readable in week one rather than week six. Break Into Banking covers it end to end. When the interfaces you catalogue are APIs, API Documentation from Scratch shows how to document endpoints, payloads, errors, and auth so the catalogue links to something precise. For the Kafka arrows, Automate Kafka Validation with Postman proves events are produced and consumed correctly, which is how you verify a catalogue row instead of trusting it. And for the AI side of the method, transcribing diagrams and diffing them against your evidence, AI at Work: MCP, RAG, and AI Agents explains the tools in practical terms. The free downloads are a good place to start, and if you want a second pair of eyes on your own landscape, book a 1:1 coaching call.

Next in the series: part 11, the 90-day review, where you prove your onboarding and leave a better guide for whoever joins after you.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Systems Analyst, Onboarding, ISO 20022, Integration, Payments