Obsidian as an Analyst's Second Brain: The Vault That Survives a Payments Programme

An analyst’s second brain is a local, plain-text, linked note vault that captures the knowledge a delivery programme generates and would otherwise lose. Built in Obsidian, it holds one atomic note per ISO 20022 message, reason code, interface, and business rule, linked to each other and to the tickets that touched them, so the fifth time you meet an AC01 rejection you are extending a note rather than starting from nothing.

Every analyst on a payments programme learns the same things twice. You work out exactly what Dbtr/PstlAdr requires under the scheme’s usage guideline in March, write it into a specification, and in September, on a different workstream, work it out again from the same PDF. The knowledge was captured, in the sense that it exists in a Confluence page somewhere, but it was not retained, because the page is a document about a delivery, not a note about the field. A second brain fixes the retention problem: knowledge is stored by concept, not by project, so it accumulates.

Obsidian is the right tool for this because of what it refuses to be. It is not a database and not a service. It is an editor over a folder of Markdown files on your own machine, which means the vault is greppable, scriptable, diffable in git, portable to any other tool, and readable in ten years when the current wiki has been migrated twice. For an analyst who already works in Markdown, git, and the terminal, the vault is just another repository.

I keep one vault across every engagement, and the ISO 20022 notes in it have been through four programmes. The templates and deliverable structures that those notes feed into are in Real-World BA Deliverables.

What is a second brain, in analyst terms?

A second brain is an external, searchable store of the knowledge you would otherwise have to hold in your head or rediscover. The popular framing is capture, organise, distil, express. The analyst translation is more specific.

Capture is everything that arrives during delivery: the answer a payments SME gave in a corridor, the reason a scheme rejects a message, the undocumented behaviour you found in the logs at 2am. Organise is putting each fact in the note where you will look for it, which is the note about the concept, not the note about the meeting. Distil is rewriting the note in your own words until it is a standalone answer. Express is the specification, the test case, the runbook, and the Confluence page that you generate out of the vault when the programme asks for a deliverable.

The failure mode of most analyst note taking is stopping after capture. A folder of meeting minutes is a transcript, not a brain. The value appears at the distil step, when the fact about PstlAdr moves out of “2026-03-12 payments sync” and into a note called pacs.008 Dbtr postal address that you will actually find later.

How should an analyst structure the vault?

Structure by note type, not by project, because projects end and note types do not. Six top-level folders carry a working analyst vault.

vault/
├── 00-inbox/          unsorted capture, emptied weekly
├── 10-daily/          one note per working day
├── 20-domain/         durable reference: messages, codes, interfaces, rules
├── 30-drafts/         specifications and analyses in progress
├── 40-runbooks/       production support procedures
├── 90-templates/      note templates

Nothing is named after a client or a programme. A note about the pacs.008 message is in 20-domain/, and the fact that you first wrote it during the SEPA migration is recorded by a link and a tag, not by a folder. This is what lets the vault survive a job change: the domain folder is the part that keeps its value, and it is the part that is entirely about the industry rather than about the employer.

Inside 20-domain/, keep notes atomic. One note per message type, per reason code family, per interface, per business rule. A note is atomic when its title is a thing you would search for, and when its body answers one question completely. AC01 IncorrectAccountNumber is a note. Payment rejections is a folder disguised as a note, and it will grow into a document nobody reads.

What does a good domain note look like?

Here is a real shape, the note for a single ISO 20022 reason code. Obsidian properties are just YAML frontmatter, which means the same file is both a human note and a machine-readable record.

---
type: reason-code
code: AC01
family: rejection
messages: [pacs.002, pacs.004]
tags: [iso20022, rejections, payments]
---

# AC01 IncorrectAccountNumber

The creditor account number is structurally wrong or does not exist at
the creditor agent. Returned in pacs.002 as a status reason when the
payment is rejected before settlement, and in pacs.004 when the funds
have already moved and must come back.

## What it means operationally
Repair is possible. The payment is not fraudulent and the parties are
valid, so the standard handling is to route it to the repair queue for
an account correction rather than to fail it back to the originator.

## Distinguish from
- [[AC04 ClosedAccountNumber]]: the account existed and is now closed,
  which is not repairable and must be returned.
- [[RC01 BankIdentifierIncorrect]]: the agent BIC is wrong, not the
  account.

## Seen in production
2026-03: 60% of our AC01 volume came from one corporate file where the
IBAN check digits were recomputed after a truncation in the upstream
system. Root cause was upstream, not the payment rail.

## Links
- [[pacs.002 Payment Status Report]]
- [[Reason code to customer message mapping]]
- Reference: [ISO 20022 reason codes](/articles/iso-20022-reason-codes)

Three things make this note earn its place. It is written as a standalone answer, so you can lift it into a specification without editing. It distinguishes the concept from its neighbours, which is where real analyst value lives, because AC01 versus AC04 is a repair decision worth money. And it carries a production observation, which is knowledge no reference document contains.

The Seen in production section is the part that compounds. After three programmes it is a body of evidence about how the standard behaves in the wild, and it makes your reason code mapping work on the next engagement an hour of assembly rather than a week of investigation.

How does the daily note support production work?

The daily note is the investigation log. When a payment fails in production, you are going to trace it across five systems, and the trace is exactly the material that a runbook is made of. Capture it as it happens, in one note, and promote it later.

---
date: 2026-09-05
tags: [daily, incident]
---

# 2026-09-05

## INC-4471 pacs.008 stuck in validation
- UETR: [redacted, in ticket]
- Symptom: 340 payments in VALIDATED, none moved to ACSP in 40 min
- Log query used: see [[Splunk queries for payment tracing]]
- Found: scheme ack consumer lag, not a message problem
- Transition it should have made: [[Payment state machine]] VALIDATED -> ACSP
- Promoted to: [[Runbook consumer lag on scheme acks]]

## Notes
- Confirmed with SME: LEI is optional for us until phase 2 -> updated
  [[pacs.008 party identification]]

Two habits make this work. First, the UETR and any real payment identifier stay in the ticket, and the note references the ticket. Notes get synced, shared, and indexed; production identifiers belong in the systems that control who can read them. Second, every finding ends with an arrow: promoted to a runbook, or updated into a domain note. A daily note whose findings never move is a diary. The promotion step is what turns a night of reading production logs into an asset, and it is the same discipline that separates analysts who accumulate production support skill from those who accumulate incidents.

How do you query the vault instead of browsing it?

Once notes carry properties, the Dataview plugin turns the vault into a queryable store. This is where the structure pays off, because the same notes assemble into different views on demand.

```dataview
TABLE code AS "Code", family AS "Family", messages AS "Seen in"
FROM "20-domain"
WHERE type = "reason-code"
SORT code ASC
```

That is a live reason code reference table that maintains itself. Two more that earn their keep on a delivery:

```dataview
LIST
FROM "30-drafts"
WHERE status = "in-review" AND contains(reviewers, "payments-sme")
```

```dataview
TABLE file.mtime AS "Last touched"
FROM "20-domain"
WHERE contains(tags, "iso20022") AND file.mtime < date(today) - dur(6 months)
SORT file.mtime ASC
```

The second one is a staleness check. Domain notes rot quietly, especially around a moving target like the structured address deadline, and a query that surfaces the notes you have not touched in six months is a cheaper review process than remembering to review.

How does the vault connect to Jira and Confluence?

Set the direction of flow deliberately, because a vault that tries to be a second source of truth becomes a liability.

System	Role	Flow
Jira	Source of truth for work status	Read into the vault, never written from it
Confluence	System of record for approved artifacts	Published from the vault, not read into it
Obsidian	Thinking, drafting, and durable domain knowledge	The place work is made, not the place it is announced

Jira into the vault is a read-only sync. A short script authenticated with a personal access token calls the search endpoint, and writes one note per issue with the key, status, assignee, and summary as properties. Those notes are stubs whose only job is to be linkable: when your AC01 note says [[PAY-3312]], the graph now connects a domain concept to the ticket that taught you it. Never edit the stubs, and regenerate them on each run, because the moment somebody trusts the vault’s copy of a ticket status over Jira’s, the vault has become a problem. The full script, the authentication, and the pagination are covered in automating Jira and Confluence with the REST API.

The vault into Confluence is the publish step. You draft the functional specification in Markdown where linking and version control are cheap, get it to a state you would defend, then push it as a Confluence page through the API or paste it in. What reaches Confluence is the finished artifact, structured the way a functional specification should be, not your working notes. The distinction protects both sides: your notes stay honest and unpolished, and the system of record stays authoritative.

The technical fluency behind all of this, scripting, APIs, and working in files rather than in tool screens, is exactly what The Technical Skills Guide for BAs is built around.

What must never go in the vault?

The vault is unencrypted plain text, usually synced to a git remote, and increasingly indexed by an AI assistant you pointed at the folder. Treat every file as if a machine you do not control will read it, because one probably will.

Never in a note: API keys, personal access tokens, passwords, connection strings, or private keys. Never in a note: production payloads containing real names, IBANs, or card numbers, and no full customer records pulled from a database while investigating. Never in a note: anything from a client engagement that the contract says stays in the client’s systems.

The workable substitutes are simple. Reference a credential by name and location, as in “uses JIRA_PAT from the shell environment, rotated quarterly”, so the note documents the mechanism without carrying the secret. Redact identifiers in examples down to a shape, UETR: 8f2a...c41, which preserves the teaching value and loses the traceability to a real customer. Keep a .gitignore that excludes any local scratch folder where API responses land during scripting. If the vault syncs to a remote, that remote is private, and the credential handling for the whole toolchain is covered in API keys, PATs, and OAuth tokens.

Why does a linked vault matter more now that AI is in the loop?

A local Markdown vault is the highest quality context you can hand a language model, and the reason is that you wrote it. Public documentation tells a model what the ISO 20022 standard says; your vault tells it what your scheme’s usage guideline actually requires, which fields your upstream system truncates, and which rejection is repairable in your operation. Point an assistant at the vault and the answers stop being generic.

This changes the economics of note taking. The distil step used to pay off only when you personally reread the note. Now a well-written atomic note is also a retrieval unit: it is exactly the chunk an assistant will pull, and a note that is a standalone answer retrieves well while a rambling meeting transcript retrieves badly. Writing notes as self-contained answers was always good practice, and it is now the difference between an assistant that drafts your test cases correctly and one that invents plausible field names. Turning that vault into repeatable tooling is the subject of Claude Skills for analysts.

It also raises the stakes on the previous section. The same property that makes the vault useful to a model, that everything is plain text in one folder, makes a leaked credential in a note a real incident rather than a slip.

The takeaway

An analyst’s second brain is a local, plain-text, git-backed Obsidian vault organised by note type rather than by project, so the knowledge outlives the programme. Keep domain notes atomic, one per message, reason code, interface, or rule, each written as a standalone answer that distinguishes the concept from its neighbours and records what you saw in production. Use the daily note as an investigation log and promote every finding into a runbook or a domain note before the day ends.

Set the direction of flow deliberately: Jira reads into the vault as disposable stubs, Confluence receives finished artifacts published out of it, and credentials and production data never enter it at all. Do that for one programme and the second one starts with an asset instead of a blank page.

Start with Real-World BA Deliverables for the artifact templates your vault should produce, and Break Into Banking for the payments domain knowledge worth writing notes about, or browse everything at The Tech BA Toolkit.

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: Knowledge Management, Obsidian, Business Analysis, Payments, Productivity