Onboarding as a Functional Analyst: Learn the Rules the System Actually Enforces

A functional analyst is onboarded when, for any rule in their scope, they can say where it is written, where the system enforces it, and what evidence proves the two agree. Get read access to configuration in week one, read every specification against both the standard it claims to implement and a real message the system produced, build a rules inventory as you go, and make your first deliverable one corrected row with evidence.

In my first week on a payment hub implementation team, the team that owned the mapping specification between legacy MT103 messages and outbound ISO 20022 pacs.008, a compliance analyst sent a short email to the team inbox. A correspondent bank had asked, in a request for information, who the payment was really on behalf of. Our pacs.008 had a debtor, the corporate client, but no Ultimate Debtor, even though the client’s original instruction had named the subsidiary it was paying for. Could someone explain why the ultimate debtor sometimes disappears?

Nobody on the team answered for two days, because everybody assumed someone else knew. I was the new functional analyst, I had no other work yet, and I said I would look. It turned out to be the best onboarding exercise I have ever had, because answering it required learning the mapping specification, the usage guideline, two channels, a configuration table, and the difference between what the team believed the system did and what it did.

This is part seven of The First 90 Days, the series on succeeding in a new team as a technical analyst. Parts one to five cover the levers every analyst uses: the plan, documentation, AI, questions, and feedback. Parts six to ten apply them to one role each. This one is for the functional analyst, whose job is the precise behavior of the system: what it accepts, what it transforms, what it rejects, and why.

What does “onboarded” mean for a functional analyst?

The business analyst’s finish line is knowing who decides. The functional analyst’s is knowing what is enforced. Three statements you can make honestly by day 90:

1. I can locate any rule. For a rule in my scope, I know where it is written and where the system enforces it, whether that is a configuration table, a validation in code, a mapping, or a manual step in operations.
2. I know where the documents lie. I can name the parts of the specification that match the system and the parts that do not, with evidence for each.
3. I have corrected something. At least one mapping, validation, or translation that was wrong has been fixed, with evidence and a traced requirement, because I found it.

The trap for a new functional analyst is to treat the specification as the system. The specification is a claim about the system. Your onboarding is the process of testing that claim.

Where do the real rules live?

In a payment hub, very few of the rules that decide a payment’s fate are in the functional specification. They are spread across:

Where	What lives there	How you get to see it
Configuration tables	Validation rules per channel, routing by currency and BIC, enabled message versions	Read access to the configuration screens or the underlying tables, requested in week one
Mapping specification	Source field to target element, with transformation rules	The team’s spreadsheet or Confluence page, plus its version history
Mapping code or templates	What the mapping actually does	A developer walking you through it, or read access to the repository
Reason code mapping	Which internal error becomes which ISO 20022 reason code, and which customer message	Usually a table owned by nobody in particular
Cut-off calendar	Per currency and per scheme deadlines, holiday calendars	Operations, or a configuration table
Usage guidelines	What the scheme or network requires, for example CBPR+ on SWIFT MyStandards	MyStandards access, which your bank already has
Operations procedures	The manual rules applied when the system cannot decide	Shadowing the exceptions desk

Ask for read access to configuration on your first day. It usually takes a week or two to arrive, which is why you ask on day one. In the meantime, ask a developer or an operations analyst to show you the screens for half an hour. Seeing the validation table for the corporate channel told me more about what the hub enforced than the forty-page specification.

How do you read a mapping specification against the standard and real messages?

Three sources, side by side, one row at a time. This is the method I used on the ultimate debtor question, and it is the method I now use in every new team.

Source one: the mapping specification. The row for Ultimate Debtor said:

Target element (pacs.008)	Source	Rule
CdtTrfTxInf/UltmtDbtr/Nm	Ultimate debtor name from source	Map if present

“Map if present.” Reasonable. It also hides the question: present in which source?

Source two: the usage guideline. The CBPR+ usage guideline for pacs.008 on MyStandards describes Ultimate Debtor as the party on whose behalf the debtor makes the payment, and expects it when such a party exists. Usage guidelines explains how to read one; the point here is that the guideline treats the ultimate debtor as information about the payment, not as an optional nicety. Payments on behalf of a subsidiary should carry it.

Source three: real messages. I asked a tester for ten outbound pacs.008 messages from the test environment, five from each of the two channels that fed the hub. The corporate file channel, which received pain.001 from clients, produced pacs.008 with UltmtDbtr populated whenever the client had sent one. The treasury channel did not, ever. The treasury system sent its instructions to the hub as MT103, and MT103 has no field for an ultimate debtor. “Map if present” was correct, and on that channel it was never present.

That was the answer to compliance’s question, and it was not a mapping defect in the narrow sense. It was data truncation through a legacy hop: an internal system still speaking MT, feeding a hub that speaks ISO 20022, with the richer data lost before the hub ever saw it. The same class of problem that MT to ISO 20022 migrations are full of, inside the bank’s own walls.

Each disagreement between the three sources is one of three things:

• A defect. The system does not do what the specification and guideline both say.
• An undocumented decision. Someone decided, sensibly or not, and never wrote it down. Find who, and write it down.
• A stale document. The specification describes an older version of the guideline or the system. Note which version it was written against.

The ultimate debtor turned out to be the third and a little of the second: the specification predated the treasury channel’s connection to the hub, and nobody had revisited the row when the second channel arrived.

What is a rules inventory, and why build one in your first month?

A rules inventory is a table with one row per rule and four columns that matter: what the rule says, where it is written, where it is enforced, and the evidence that they agree. I start one on day one in every new team and add a row every time someone says “the system always does X” or “we never allow Y.”

ID     RULE                                SOURCE                     ENFORCED WHERE                 EVIDENCE                         STATUS
R-014  UltmtDbtr populated when payment    CBPR+ pacs.008 guideline;  Mapping, corporate channel     Test msgs CORP-01..05: present   GAP on treasury
       is on behalf of another party       mapping spec row 41        only; treasury channel MT103   Test msgs TRSY-01..05: absent    channel
R-022  Creditor address: town and country  CBPR+ Nov 2026; product    Hub validation table,          Config screenshot 2026-10-08;    MATCH
       structured or reject to repair      decision (hybrid accepted) rule ADDR_HYB_01               negative test TC-ADDR-07
R-031  GBP payments after 15:30 roll to    Ops procedure v3           Cut-off calendar table         NOT VERIFIED: no test found      UNKNOWN
       next business day                                              (per operations, unconfirmed)
R-040  Internal error E1107 maps to        Reason code mapping sheet  Hub reason code table          Config differs: table says AC04, MISMATCH
       pacs.002 reason AC01                                                                          sheet says AC01

Three things make this more useful than it looks:

• The UNKNOWN status is honest. Most new analysts write down what they were told. Writing NOT VERIFIED makes the gap visible, and each one is a question with a clear owner.
• It becomes the test basis. Every row with evidence is a test case waiting to be written; every row without evidence is a risk. QA analysts love this artifact, and it is the fastest way to earn their trust.
• It survives you. The next functional analyst inherits a map of what is enforced where, instead of the forty-page specification.

Where rules interact, for example when the ultimate debtor is required depending on channel, on-behalf-of indicator, and payment type, a decision table is clearer than prose. If you keep the inventory in a spreadsheet, a few lookup and filter formulas turn it into a coverage view; Excel for Business Analysts covers the patterns.

How should a functional analyst use AI during onboarding?

As a tireless comparer of documents, never as a source of rules. Use only your organization’s approved tool, and never paste production messages containing real names, accounts, or addresses. Masked test messages are fine where your policy allows them.

Diff the specification against the guideline. Paste the mapping specification rows for one message and the relevant guideline extract, and ask:

Compare the mapping rows against the usage guideline extract.

For each target element in the guideline extract, report:
- MAPPED: the spec row that populates it, quoted
- NOT MAPPED: the guideline expects it and no spec row populates it
- CONDITION GAP: the guideline has a condition the spec row ignores
- VERSION: any sign the spec was written against a different version

Use only the two texts I pasted. If something cannot be decided from
them, write CANNOT TELL FROM SOURCE.

Explain a message you do not understand yet. Paste a masked test pacs.008 and ask the model to walk through it element by element, stating for each what the element means in the standard, without guessing what your bank uses it for. It is a fast tutor for the standard; it knows nothing about your configuration.

Draft the first pass of the rules inventory from meeting notes, then verify every row yourself. The model will produce plausible rules that nobody stated. That is why the EVIDENCE column exists.

Part three covers building the full AI onboarding pack. For a ready library of comparison and gap-finding prompts, see The Tech BA Prompt Toolkit.

What questions should a new functional analyst ask?

Precise ones, about specific rows and rules, each with your evidence attached. Part four has the general format: what I checked, what I found, what I think it means, what I need from you. For a functional analyst, the most productive questions in month one were:

• “Which version of the guideline was this specification written against?” If nobody knows, the answer is in the document history, and it tells you how stale everything else is.
• “When this rule was decided, who decided it?” For every rule that is not in the guideline. The undocumented decisions are where the risk is.
• “Which channels feed this message, and were they all live when the spec was written?” That one question would have answered the ultimate debtor issue in a day.
• “What happens to a message that fails this validation?” Reject, repair queue, or silently defaulted. Silent defaults are the dangerous ones.
• “Where does this internal error code become a customer message?” It is always further away than you think, and the reason code mapping is often owned by nobody.

How do you give feedback on a specification you did not write?

Carefully, because it is someone’s work and they are probably in the room. Part five has the method. The functional analyst version is to make feedback about the evidence, never about the author.

When I reported the ultimate debtor finding, I did not say “the spec is wrong.” I wrote: “Row 41 maps UltmtDbtr when present in the source. On the treasury channel the source is MT103, which has no field for it, so it is never present. Test messages TRSY-01 to 05 attached. The row was correct when written, before the treasury channel connected. Proposed change below.” The author of the specification replied with a thank you and the history of why the treasury channel had been connected late, which became two more rows in my inventory.

Why should your first deliverable be one corrected row?

Because it shows the whole job in miniature: reading the standard, reading the system, finding the gap, and fixing it precisely. A new functional analyst who produces a rewritten specification in month one has produced an opinion. One who produces one corrected row with evidence has produced a fix.

The corrected row for the ultimate debtor looked like this:

Target element	Channel	Source	Rule	Evidence
UltmtDbtr/Nm	Corporate files	pain.001 UltmtDbtr/Nm	Map as received	CORP-01 to 05
UltmtDbtr/Nm	Treasury	Treasury system on-behalf-of entity (new field in the internal interface)	Map when the on-behalf-of flag is set; if the flag is set and the name is empty, route to repair	TRSY-06 to 08, written after the change

It needed a small change to the internal interface, which the treasury team accepted because the finding came with the correspondent’s information request attached. The requirement it traced to was the compliance obligation to identify the party a payment is made for. The specification gained a channel column it should always have had.

If no mapping defect is waiting for you, the classic alternative first deliverable is a reason code mapping table: every internal rejection reason, the pacs.002 reason code it produces (AC01 incorrect account number, AC04 closed account, AM04 insufficient funds, BE04 missing creditor address, and the rest), and the customer-facing text each one triggers. In nearly every team I have joined, at least one line of that table was wrong, and fixing it changed what real customers were told. ISO 20022 reason codes is the reference.

Either way, the format of the work is the same as any functional specification: rule, source, condition, behavior, evidence. And if you are on a package implementation rather than a build, the same three-source method is how you run a fit-gap analysis: the standard, the package configuration, and a real transaction.

What does a 90-day plan look like for a functional analyst?

Weeks	Focus	Output you can show
1 to 2	Request configuration access; read the spec for your main message; start the rules inventory	Inventory with 20+ rows, most marked NOT VERIFIED
3 to 4	Three-source read of one message: spec, guideline, real messages	Discrepancy list classified as defect, undocumented decision, or stale
5 to 6	Pick one discrepancy and take it to closure	Corrected row with evidence, reviewed by the spec author
7 to 8	Extend to the second message and the reason code mapping	Reason code table checked against configuration
9 to 10	Own the specification for a change; write it with the channel and evidence columns	Your first specification, traced to requirements
11 to 13	Hand the inventory to QA as a test basis; 90-day review	Inventory reviewed by QA; onboarding notes for the next joiner

Part eleven covers the review and what to leave behind.

The takeaway

Functional analyst onboarding is learning what the system enforces, not what the specification says. Get configuration access on day one. Read every specification against the guideline it claims to implement and against real messages the system produced, and classify every disagreement as a defect, an undocumented decision, or a stale document. Build a rules inventory with an evidence column and be honest about what you have not verified. Then fix one row, with evidence, and trace it to the requirement it serves.

The method for turning a rule like “identify who the payment is for” into a buildable functional requirement is the whole of From Vague BR to Functional Requirements. For the payments domain behind it, correspondents, channels, and why an MT hop still exists inside a bank in 2026, see Break Into Banking. If your employer is still deciding whether you may use AI on work like this, The AI-Powered Analyst covers working within that constraint. The free downloads include templates you can start the inventory from.

To practise reading a contract against requirements on a system you have never seen, Mission 01 on the Labs hands you an OpenAPI contract and a set of business rules and asks for a gap register, which is the rules inventory under another name. The Review Scorecard gives you twelve checks to run on any contract you inherit. The rest of the series is on The First 90 Days.

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: Functional Analysis, Onboarding, ISO 20022, Payments, Specifications