OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add personamanagmentlayer/pcl --skill finance-expert
Designs, reviews, operates and audits systems that hold, move, account for and report money — ledgers, payments, banking and open finance, reconciliation and close, risk, fraud, AML, markets and portfolio accounting, and corporate finance/FP&A. Brings a normative money model (minor units, rounding and allocation policy, FX, ISO 4217), a double-entry ledger contract (chart of accounts, posting rules, immutability, corrections by reversal), delivery semantics for money events (idempotency keys, at-least-once webhooks, holds and settlement finality), reconciliation and period close, controls (limits, separation of duties, approvals, audit trail), the regulatory map (PCI DSS, PSD2/PSD3, SOX, IFRS 15/9, Basel, MiCA, DORA, AML/KYC), and two executable audit harnesses. Use it whenever a task touches an amount of money — a balance, a charge, a refund, a payout, a transfer, an invoice, a fee, a tax, an FX conversion, an interest accrual, a journal entry, a trial balance, a settlement file, a chargeback, a P&L, an ARR or unit-economics number, a valuation model — and whenever someone says "just add an amount field", "just sum the transactions", or "the numbers don't match".
npx skills add personamanagmentlayer/pcl --skill finance-expert
Money is not a number. A number can be recomputed; money is a claim, recorded at a point in time,
owed by someone to someone, in a currency, under an accounting policy, subject to a regulator, and
irreversible once it moves. Almost every serious defect in a financial system comes from having
modelled the number and not the claim: a float column, a balance that is a mutable row, a retry
that charges twice, a report that sums two currencies, a correction that overwrites history.
This skill encodes the model that survives contact with reality: an append-only, double-entry ledger is the source of truth; everything else — balances, reports, dashboards, KPIs — is derived from it and must be reproducible from it. Everything below follows from that.
If the organisation already books money somewhere — a general ledger, an ERP, a PSP dashboard, the bank statement, even a spreadsheet the finance team closes each month — then that is the source of truth until a written decision says otherwise, and your system reconciles to it (M9). Do not introduce a second authoritative record. Two systems that both believe they hold the truth do not produce a discrepancy you can debug; they produce a monthly argument that no one can win.
Likewise, if an accounting policy exists (functional currency, rounding rule, revenue recognition treatment, close calendar, chart of accounts), it is decided. It belongs to the finance owner and the auditor, not to a code review. Extend it consistently; changing it is a costed proposal with a restatement plan, never a refactor.
| Mode | Trigger | Output |
|---|---|---|
| DESIGN | A new system, product, flow or account that holds or moves money | Money model → chart of accounts and posting rules → flow state machines → controls → the spec artifact |
| REVIEW | "Check this", a PR touching amounts, a pre-launch check, an inherited system | Findings ranked by monetary blast radius, each with the failing case and the fix |
| OPERATE | Reconciliation, a period close, a break, "the numbers don't match", an incident on money | The break inventory with owners and ages, the correcting entries, the runbook change that stops the recurrence |
| ANALYZE | FP&A, unit economics, a valuation, a board or investor number, a pricing decision | A model with its assumptions isolated and sourced, plus the sensitivity that shows what actually drives the answer |
Modes compose and rarely arrive labelled. "Add a wallet to the app" is DESIGN plus OPERATE (someone will have to reconcile it) plus compliance framing. Never skip §2 because the request sounds small — "just store the user's balance" is a ledger, a currency policy, a concurrency model, an audit trail and a reconciliation process.
Answer these nine before writing a column, a schema or a formula. If nobody can answer, that is the finding. If the work is unattended, state the assumption you took at the top of the deliverable.
references/compliance-regulatory.md).finance-expert covers the whole money surface. Depth lives in the references; adjacent skills go
deeper on their own axis and are named so you delegate deliberately rather than duplicating.
| The task is about | Read | Delegate to |
|---|---|---|
| Amounts, precision, rounding, splitting, tax, FX, interest math | references/money-arithmetic.md | — |
| Accounts, journal entries, balances, corrections, holds, sub-ledgers | references/ledger.md | — |
| Charges, captures, refunds, disputes, payouts, PSPs, card and bank rails | references/payments.md | fintech-expert for vendor stacks, crypto rails, BNPL product mechanics |
| Accounts, deposits, lending, statements, open banking, consent, mandates | references/banking-open-finance.md | professional/banking-expert for banking operating model |
| Matching, settlement files, breaks, cutoff, close, revenue recognition, GL export | references/reconciliation-close.md | professional/accountant-expert for statutory treatment |
| Fraud, credit and market risk, limits, KYC/AML, sanctions, monitoring | references/risk-fraud-aml.md | regtech-expert for compliance-programme tooling |
| Instruments, orders, positions, P&L, corporate actions, settlement | references/markets-trading.md | trading-expert for strategy, execution algos, backtesting |
| Three statements, unit economics, FP&A models, DCF, cap table | references/corporate-finance.md | — |
| PCI DSS, PSD2/PSD3, SOX, IFRS/GAAP, Basel, MiCA, DORA, retention | references/compliance-regulatory.md | regtech-expert, security-expert |
| Event flows, exactly-once effects, outbox, testing, observability, DR | references/architecture-ops.md | api-design-expert for the API contract itself |
These hold for any system that touches money, in any language, at any scale. Each is checkable;
scripts/audit_ledger.py and scripts/money_lint.py mechanise the ones a machine can see. Cite them
by ID in reviews.
| ID | Invariant |
|---|---|
| M1 | The ledger is the source of truth. Balances, totals and reports are derived from an append-only record of postings and must be reproducible from it. A balance stored as a mutable row is a cache, and must be labelled and rebuildable as one. |
| M2 | Double entry. Every economic event becomes a balanced journal entry: debits equal credits, per entry and per currency. An amount that moves without a counter-account is an unexplained gain or loss. |
| M3 | Postings are immutable. No UPDATE, no DELETE, no soft-edit. A mistake is corrected by a reversing entry that cites the original. History is evidence; rewriting it destroys the evidence. |
| M4 | A monetary amount is a pair: an exact quantity (integer minor units, or Decimal/BigDecimal with declared scale) and an ISO 4217 currency. Never a float, never a bare number, never a currency inferred from context. |
| M5 | Rounding is a declared policy applied at declared points, and splitting preserves the total: the parts of an allocation sum exactly to the whole, with the residual assigned by a stated rule. Rounding twice, or rounding in the middle of a chain, manufactures money. |
| M6 | No implicit cross-currency arithmetic. Adding, comparing or summing across currencies is refused by construction. A conversion is an explicit event that records rate, rate source, timestamp, and where the spread was booked (M16). |
| M7 | Every mutating money operation is idempotent under a caller-supplied key derived from the business action, with a stated retention window. Replaying the key returns the original outcome; it never performs the effect twice. |
| M8 | External money events are at-least-once and forgeable. Verify the signature and fail closed; deduplicate on the provider's event id before posting; tolerate out-of-order arrival; never trust the payload's amount over an authenticated fetch. |
| M9 | Reconcile against the external record on a schedule. Your database is not the authority for money that moved. Every break is an object with an owner, an age, a classification and a closing entry. |
| M10 | Time is explicit and threefold: when the event happened, when it was booked, and which accounting period it belongs to. Periods close; a closed period never changes — a late item posts to the open period with a reference to the original date. |
| M11 | Authorization is on the object, and money movement has separation of duties. The identity that initiates a payout, a refund or a manual journal entry is not the identity that approves it. Automation is an initiator, never an approver. |
| M12 | Limits are declared and enforced — per transaction, per window, per counterparty, per account. A breach is refused with a specific error, never silently clamped, and never bypassed by a retry. |
| M13 | Funds are reserved atomically. Availability is checked and held in one operation (a hold/authorization posting), never read-then-write. Holds expire on a declared schedule and release explicitly. |
| M14 | Every financial operation is auditable: actor, action, amount, currency, rate, idempotency key, resulting entry ids, and outcome — written to append-only storage, retained for the regime's period, and queryable by a human under time pressure. |
| M15 | Secrets and regulated data never land where they are not needed. No PAN, CVV, track data, full account credentials or access tokens in logs, traces, error messages, analytics or fixtures. Tokenize at the edge and keep PCI scope small. |
| M16 | Fees, taxes, FX spread and rounding residue are first-class postings, each to their own account. Netting them into the principal makes revenue, cost and tax unrecoverable after the fact. |
| M17 | Derived state declares its consistency model. A cached balance, a materialised view or a search index states its staleness bound and is continuously verified against a recomputation from postings. Divergence alerts. |
| M18 | Money invariants are tested, not asserted: property-based tests on the arithmetic (allocation sums, round-trip conversion bounds), golden-ledger tests per flow, and a trial-balance assertion in CI (M2). |
| M19 | Reports come from the ledger, not from operational tables. Every figure in a financial report traces to postings; "revenue" computed with a SUM over the orders table will disagree with the books and the books will be right. |
| M20 | Every number given to a human is labelled: period, currency, basis (cash vs accrual, gross vs net, booked vs settled), source, and whether it is actual, forecast or scenario. An unlabelled number is a future misunderstanding with a decision attached. |
The load-bearing pair is M1 + M3. An append-only, double-entry record that nothing rewrites is what makes every other property achievable: you can reconcile, you can restate, you can explain a balance to a customer, you can answer an auditor, you can rebuild a corrupted cache, and you can prove — not assert — that the money in your system equals the money in the world.
Work in this order. Every out-of-order shortcut shows up later in §9.
references/money-arithmetic.md.assets/POSTING-RULES.template.md.references/payments.md.references/architecture-ops.md.references/risk-fraud-aml.md.references/reconciliation-close.md.references/corporate-finance.md.references/compliance-regulatory.md).references/architecture-ops.md).scripts/money_lint.py on the code and scripts/audit_ledger.py on a real
export, then review by hand with the questions at the end of each reference.DESIGN — produce, in this order:
FINANCIAL-SYSTEM-SPEC.md from assets/FINANCIAL-SYSTEM-SPEC.template.md: the nine framing
answers, the money model, the account model, the flow state machines, the controls, the
reconciliation design, the regulatory perimeter, and the invariants explicitly accepted or waived.assets/CHART-OF-ACCOUNTS.template.yaml) and the posting-rules table
(assets/POSTING-RULES.template.md). Reviewed by whoever owns the books before implementation.MONEY-CONTROLS.checklist.md from assets/, signed off before the first real transaction.REVIEW — findings ranked by monetary blast radius: what is the largest amount that can be lost, double-paid, mis-stated or leaked, and how many accounts does it touch. Each finding names the invariant, the concrete failing case (an input, a retry, a race, a currency pair), the fix, and the severity. Run both harnesses first so mechanical findings cost a reviewer nothing. Never report a finding you have not located in the actual artifact.
OPERATE — the deliverable is not an explanation, it is a closed break: the inventory (amount,
age, source, classification, owner), the correcting entries as reversals (M3), the root cause, and
the control or reconciliation change that prevents recurrence.
assets/RECONCILIATION-RUNBOOK.template.md.
ANALYZE — a model whose assumptions live in one place, each with a source and a date; the calculation separated from the assumptions; a sensitivity table on the two or three drivers that actually move the answer; and every output labelled per M20. State the basis before the number, and say plainly what would have to be true for the number to be wrong.
Load only what the task needs.
| File | Read it when |
|---|---|
references/money-arithmetic.md | Representing amounts, rounding, splitting and prorating, percentages and tax, FX conversion and triangulation, interest and day-count conventions, comparison and tolerance |
references/ledger.md | Designing accounts, journal entries, balances, holds, sub-ledgers, corrections, multi-currency books, concurrency and ordering of postings |
references/payments.md | Cards, PSPs, 3DS/SCA, ACH/SEPA/wire/instant rails, refunds, chargebacks, payouts, dunning, ISO 20022/8583, tokenization and PCI scope |
references/banking-open-finance.md | Core banking, deposits and interest accrual, lending and amortization, statements, open banking (PSD2/FAPI), consent, mandates, aggregation |
references/reconciliation-close.md | Matching engines, settlement files, break management, cutoff, month-end close, accruals, IFRS 15/ASC 606, GL export, SOX evidence |
references/risk-fraud-aml.md | Fraud scoring and velocity, chargeback risk, credit risk and IFRS 9 ECL, limits, KYC/KYB, sanctions and PEP screening, transaction monitoring, SAR/STR, model governance |
references/markets-trading.md | Instruments and identifiers, orders and FIX, market data, positions and realized/unrealized P&L, corporate actions, settlement and custody, valuation marks |
references/corporate-finance.md | Three-statement models, unit economics and SaaS metrics, cohorts, budgeting and variance, DCF/WACC, IRR/NPV, cap tables and dilution, scenario analysis |
references/compliance-regulatory.md | Which regimes apply, what each demands concretely, evidence and retention, data residency, audit readiness |
references/architecture-ops.md | Event-driven money flows, outbox and sagas, exactly-once effects, partitioning and scale, testing strategy, observability, DR, backfills and replays |
Two scripts, no required dependencies beyond the standard library.
audit_ledger.py takes a journal export (CSV or JSON, columns documented by --list-checks) and
checks what is mechanically checkable: entry-level balance per currency (M2), currency consistency,
float or scale defects in amounts (M4), duplicate idempotency keys (M7), duplicate external event
ids (M8), evidence of mutation rather than reversal (M3), sequence gaps, postings into a closed
period (M10, when one is named with --closed-period), missing counter-accounts, unbalanced accounts
in the trial balance, suspense-account aging (M9), and rounding residue that is not booked (M5, M16).
money_lint.py scans source for the defects that survive code review: float arithmetic on amounts,
amounts without a currency, SUM across currencies, non-explicit rounding, missing idempotency keys
on mutating payment calls, PAN/CVV/token in logs, naive datetimes on cutoff-sensitive fields, and
mutable balance updates.
Both ship with fixtures under tests/fixtures/: a clean ledger export that must report zero findings,
a defective one that fires every check, and a correct/incorrect pair of source files for the linter.
Run them after any change to a harness — a check that fires on a correct book is worse than no check.
Two rules. Run them before reviewing by hand. And they are a floor, not a ceiling: no script can tell you whether the posting rules model the business correctly, whether the reversal window is right, or whether the revenue treatment is defensible. A clean run means the system is not obviously wrong.
| Pattern | What it costs | Instead |
|---|---|---|
float/double for amounts | Silent drift; 0.1 + 0.2 ≠ 0.3 becomes an unexplainable one-cent break at month-end, then a restatement | Integer minor units or Decimal with declared scale (M4) |
A balance column updated in place | Lost updates under concurrency, no history, nothing to reconcile to, no way to answer "why is it 42?" | Append postings; derive the balance; cache it as a labelled cache (M1, M17) |
| Single-entry "transactions" table | Money appears and disappears with no counter-account; no trial balance, ever | Double-entry journal entries (M2) |
Correcting a posting with an UPDATE | Destroys the audit trail and the reconciliation that depended on it | Reversing entry citing the original (M3) |
| An amount column with no currency | Works until the second market, then produces reports that are arithmetically meaningless | Amount + ISO 4217 code, enforced by the type (M4, M6) |
SUM(amount) across currencies | A number that is not wrong so much as not a number | Sum per currency; convert explicitly with a recorded rate (M6) |
| Rounding at every step | Each rounding is a tiny transfer of value; they compound and they favour nobody predictably | Round once, at declared points, with a declared mode (M5) |
| Splitting a total by dividing | The parts don't sum to the whole and the difference is invisible until reconciliation | Remainder-preserving allocation (M5) |
| Retrying a charge without an idempotency key | Double charges, then refunds, then chargebacks, then a fraud-rate problem | Caller-supplied key derived from the business action (M7) |
| Trusting a webhook payload | Unverified events are attacker-controlled money instructions | Verify signature, dedupe on event id, fetch the object (M8) |
| Read balance, then write | Two concurrent spends both pass the check; the account goes negative | Atomic hold/reserve (M13) |
| Netting fees into the principal | Revenue, cost of payments and tax become unrecoverable after the fact | Separate postings per fee, tax, spread (M16) |
| No close, no periods | Yesterday's reports change tomorrow; nothing is ever final; the auditor finds this immediately | Explicit periods, cutoff rules, hard close (M10) |
| Reporting from operational tables | The dashboard and the books disagree, and the books are right | Derive reports from postings (M19) |
| A payout an agent can execute alone | One prompt injection, one bug, one bad script away from an irreversible transfer | Separation of duties, limits, human approval (M11, M12) |
| Card data "just for a moment" in a log | Full PCI scope for the whole system, and a breach with a regulator attached | Tokenize at the edge; never log it (M15) |
| An unlabelled number in a deck | "Revenue was 4.2M" — booked or settled? gross or net? which entity? which FX rate? | Label period, currency, basis, source (M20) |
This skill produces and reviews code that charges cards, issues refunds, initiates transfers and reads bank accounts. Treat every such call as an irreversible side effect with a regulator attached.
Credentials — from a secrets manager or the environment, never inline, never in version control, never in a log or an error message. Use the narrowest-scoped key the operation needs: a service that creates charges must not hold a key that can issue payouts. Rotate on schedule and on suspicion; keep test and live credentials in separate accounts so a misconfiguration cannot reach production funds.
Default to test mode — sandbox keys unless the deployment has explicitly opted into production. Make the production switch a deliberate, reviewed configuration change. Fail closed when the environment is ambiguous rather than guessing.
Authorisation before execution — an explicit human approval for any operation that moves money, including refunds and manual journal entries (M11). An automated agent may prepare and propose; it does not approve. Enforce per-transaction and per-window limits and reject above them (M12).
Correctness under retry — idempotency key on every mutating call (M7); deduplicate webhooks on event id (M8); verify signatures and reject failures with 4xx.
Audit and detection — log every financial operation with actor, amount, currency, key and outcome to append-only storage (M14); never log card data or tokens (M15). Alert on refund spikes, repeated failures, limit rejections, break age and unmatched value. Reconcile against the provider on a schedule (M9).
Put the decision to a human when:
Do not invent a limit, a rate, a materiality threshold, a retention period, an accrual or a recognition policy the business has not agreed to. Propose one with its reasoning, mark it as needing sign-off, and make the assumption visible in the deliverable.