Minibank用語集

読み方

各用語を「一言説明 → 詳しい説明 → Minibankでの例」の順に掲載しています。一般論と、このリポジトリで確認できる事実を区別してください。

実際のMinibankでは

同じ言葉でも製品ごとに境界が異なります。例えばTransactionは画面遷移ではなく、DB上で仕訳・業務記録・残高cache・auditをまとめて成功または失敗させる単位として重要です。

用語一覧

Financial Intermediation資金の余る側と必要な側をつなぐ

銀行などが預金を集め、審査・risk管理を行って融資する間接金融の働き。

Minibankでの例: Minibankは融資を実装していないため、この機能全体は再現しない。

Liquidity必要時に支払える力

資産を大きく損なわず、必要な時に現金・決済資金を用意できる能力。

Minibankでの例: 顧客残高はあるが、銀行全体の流動性管理は未実装。v13の Treasury・ALM Simulator は、GLから流動資産を計算し、架空の預金流出シナリオで流動性を試算する（実際の資金繰り管理ではない）。

ALM資産・負債のずれを管理

Asset Liability Management。金額、期間、金利、通貨などのずれを銀行全体で管理する。

Minibankでの例: v13で教育用の簡易版を実装：満期別ギャップ（treasury.maturity_ladder）と、固定の架空市場シナリオでの預金流出・金利ショックの試算（treasury.run_scenario）。本格的なALM（デュレーション・EVE等）は未実装。

System of Record最終的に正しい記録

複数systemの値が異なる時に、正として扱うdata source。

Minibankでの例: 資金残高はLedgerを正とし、balance cacheを照合する。

Operational Resilience障害下でも重要業務を続ける力

障害・cyber攻撃・災害が起きても、許容範囲で重要業務を継続・復旧する能力。

Minibankでの例: 正式な耐性度やmulti-site DRは未整備。

Mandate口座振替の事前同意

預金者が特定の収納企業による口座引落しを許可した契約・記録。

Minibankでの例: 口座振替未実装のためmandateも存在しない。

Authorization Holdcard利用額の一時確保

card承認後、最終売上前に利用可能残高から金額を確保すること。

Minibankでの例: デビットcard未実装のためholdは存在しない。

Clearing参加者間の支払額を整理

取引明細を照合し、各参加機関が支払う・受け取る金額を算出するprocess。

Minibankでの例: v9から架空の決済システムSimulator（interbank.clearing_records）が受理・拒否を判定し、end_to_end_idで重複を排除する。実在のnetworkには接続しない。

Settlement参加者間の最終資金決済

clearing結果に基づき、金融機関間で最終的に資金を移すこと。

Minibankでの例: 同一銀行内の振込は銀行間決済を伴わない。v9の他行為替Simulatorでは interbank.run_settlement() が受理済みの支払を中央銀行当座預金（架空）から決済する。

Credit Risk相手が返済できないrisk

借り手や取引相手が契約どおり支払えず、銀行が損失を被る可能性。

Minibankでの例: loan未実装のため融資credit riskはmodel化していない。

Expected Credit Loss将来の貸倒れへの見積り

将来の信用損失を見積もり、会計上の引当などへ反映する考え方。

Minibankでの例: loan loss provisionは未実装。

Model Governance判断modelを継続管理する仕組み

modelのdata、精度、偏り、説明、変更、承認、停止を管理する体制。

Minibankでの例: 自動loan審査modelは未実装。

APIシステム間の入口

決められたrequestとresponseで機能を利用する境界。

Minibankでの例: `/api/v1/transfers` が振込requestを受ける。

Authentication誰であるかの確認

credentialやtokenで利用者のidentityを確かめる。

Minibankでの例: Supabase Authのaccess tokenをgetUser()で検証する。

Authorization何をしてよいかの判断

確認済みidentityへ操作・データ範囲を許可する。

Minibankでの例: auth.uid()、RLS、admin roleで判断する。

RLS行単位のアクセス制御

PostgreSQLのRow Level Security。query結果をcallerごとに制限する。

Minibankでの例: 顧客は自分のcustomers・bank_accountsだけを読む。

RPCDB関数を呼ぶ入口

Remote Procedure Call。PostgRESTからPostgreSQL functionを実行する。

Minibankでの例: 顧客はrequest_transfer() / confirm_transfer_otp()を呼び、execute_transfer()は内部処理に限定する。

Transaction全部成功か全部失敗

複数のDB変更を原子的な1単位にする。

Minibankでの例: 振込のjournal、transfer、balance cache、auditをまとめる。

Concurrency同時実行

複数requestが同じデータへ同時に作用する状況。

Minibankでの例: 送金時に両口座を決定順でFOR UPDATEする。

Idempotency再試行しても二重処理しない

同じrequest identityの繰り返しから同じ結果を得る性質。

Minibankでの例: user idとidempotency keyのunique制約とfingerprint。

OTP期限付きの確認code

One-Time Password。期限・試行回数・使用済み状態をserverで管理する。

Minibankでの例: request_transfer()がchallengeを作り、confirm_transfer_otp()が検証する。

State Machine許可された状態と遷移

現在状態ごとに、次に進める状態と操作を決めるmodel。

Minibankでの例: OTPのactive / consumed / expired / failed / superseded。

Function Overload同名で引数が違う複数関数

PostgreSQLでは名前と引数型の並びでfunctionを識別する。

Minibankでの例: 旧3引数execute_transferが残りPGRST203を起こした。

SQLSTATEDB errorの安定したcode

PostgreSQL errorをprogramが判別する5文字code。人向けmessageとは分ける。

Minibankでの例: TR010をmapRpcError()で安全な残高不足messageへ変換する。

Actor Separation顧客と管理者の役割分離

同一identityへ衝突する強い役割を同時に持たせない規則。

Minibankでの例: customer profileとactive admin operatorの兼務をDBで拒否する。

Beneficiary登録した振込先

繰り返し使う送金先の口座情報をownerごとに保存する。

Minibankでの例: transfer_beneficiariesをowner-only RPCで一覧・登録・編集・削除する。

Ledger金額変動の台帳

取引の借方・貸方を積み重ねる記録。

Minibankでの例: ledger schemaのaccounts、journal_entries、journal_lines。

General Ledger勘定別に集約した元帳

すべての仕訳を勘定科目ごとに集約し、増減と残高を説明する中心の帳簿。

Minibankでの例: Accounting Consoleがledger account別の借方・貸方・残高を集計する。v10の銀行会計画面は同じ仕訳を勘定科目（gl.accounts）別に集計する。

Subledger顧客・契約別の補助元帳

GLの統制勘定を構成する顧客、契約、商品などの詳細な内訳。

Minibankでの例: public.time_depositsの各契約がTIME_DEPOSITS_PAYABLEの内訳になる。v10では普通預金・定期預金・未決済為替・仮受金の4つをGLと照合する。

Trial Balance全勘定の借貸一覧

勘定ごとの借方・貸方・残高を並べ、全体の借方合計と貸方合計を確かめる試算表。

Minibankでの例: 管理画面のtrial balanceで会計全体の算術的な均衡を確認する。

Asset銀行が持つ経済的価値

現金、受取る権利などの資産。通常残高は借方で、借方記帳により増える。

Minibankでの例: SYSTEM_FUNDINGはMVP内部のasset勘定であり、実銀行の正式勘定ではない。

Liability銀行が返す・支払う義務

預金者など他者に対する返還義務。通常残高は貸方で、貸方記帳により増える。

Minibankでの例: 普通預金とTIME_DEPOSITS_PAYABLEは銀行側のliability。

Revenue銀行が得た収益

サービス提供の対価などとして得る価値。通常残高は貸方。預金元本とは区別する。

Minibankでの例: 手数料をFEE_REVENUEの貸方へ記帳する。

Expense銀行が負担した費用

収益を得るために消費・負担する価値。通常残高は借方。

Minibankでの例: 定期預金の満期利息をINTEREST_EXPENSEの借方へ記帳する。

Journal Entry取引1件の仕訳header

取引種別・通貨・日時をまとめる単位。

Minibankでの例: transferの1件にjournal entryを1件作る。

Journal Line勘定ごとの仕訳明細

どの勘定を借方または貸方へいくら記録するか。

Minibankでの例: 送金元debit、送金先credit。

Debit借方

複式記帳の左側。増減の意味は勘定区分で変わる。

Minibankでの例: 預金負債をdebitするとその顧客への負債が減る。

Credit貸方

複式記帳の右側。増減の意味は勘定区分で変わる。

Minibankでの例: 預金負債をcreditするとその顧客への負債が増える。

Double Entry借貸を一致させる記帳

1取引を複数勘定へ記録し、借方合計と貸方合計を等しくする。

Minibankでの例: deferred triggerがcommit時に一致を検査する。

Append-only追記のみ

既存記録を更新・削除せず、新しい記録を足す方式。

Minibankでの例: journalとauditのUPDATE/DELETEをtriggerで拒否する。

Reversal逆仕訳

誤った仕訳を消さず、借貸を反転した新仕訳で打ち消す。

Minibankでの例: reverse_transaction()が全lineのdebit/creditを交換する。

Audit Log操作の監査証跡

actor、時刻、対象、変更や業務イベントを追跡する。

Minibankでの例: audit.audit_logsへtrigger/rpc sourceを記録する。

Reconciliation別記録どうしの照合

業務記録、台帳、残高cacheなどの一致を確かめる。

Minibankでの例: run_check()がtransferとjournalを比較する。

Integrity Checkあり得ない状態の検出

保存済みデータを横断し、不変条件違反を見つける。

Minibankでの例: BALANCE_MISMATCHやACTOR_COLLISIONをissue化する。

Integrity保存状態の健全性

データが設計上の不変条件を満たし、孤立・矛盾・不均衡などの異常がない性質。

Minibankでの例: Integrity Checkが台帳やactorの異常を検出する。

KYC顧客本人確認

Know Your Customer。顧客の確認状態を管理する。

Minibankでの例: not_started→pending→verified/rejected。

Admin Control Plane管理操作専用の制御面

通常利用とは分離した、高権限操作・role・監査の仕組み。

Minibankでの例: admin schemaとauthenticated向けadmin RPC。

Regression Test以前の動作を守るテスト

変更後も過去の契約が壊れていないか確認する。

Minibankでの例: DB/RPC suiteとAPI suiteをrun-regressionで実行する。

E2E Test端から端までのテスト

Browser操作からbackendと画面反映まで一連で確認する。

Minibankでの例: Playwright full-journey.spec.ts。

Requirement満たすべき条件

誰の問題を何によって解決し、どの条件なら受け入れるかを定める。

Minibankでの例: 二重送金せず、借貸一致をDBで保証する。

RFP提案依頼書

発注側が背景・目的・範囲・条件・評価方法を示し、候補企業へ提案を求める文書。

Minibankでの例: 台帳、security、移行、運用条件を同じ基準で比較する。

Agile小さく作り早く学ぶ

短い周期で動く価値を届け、feedbackから計画を更新する考え方。

Minibankでの例: 画面改善を小さくreleaseしbacklogを更新する。

Waterfall段階ごとに合意して進む

要件・設計・実装・testなどの成果物と承認点を明確にする進め方。

Minibankでの例: 会計不変条件を設計審査後に実装する。

Sequence Diagram処理を時間順に示す図

登場人物間のrequestとresponseを上から下へ並べる。

Minibankでの例: 画面→API→Auth→RPC→Ledgerを追跡する。

Library呼び出して使う道具

特定の機能を再利用可能な形で提供するsoftware部品。

Minibankでの例: React、Zod、Supabase JavaScript client。

Frameworkapplicationの骨組み

全体構造や実行の流れを提供し、その規約上でcodeを動かす。

Minibankでの例: Next.jsがrouteやrenderingの枠組みを提供する。

Containerimageから動く隔離された実体

applicationと依存物を再現可能な実行単位として動かす。

Minibankでの例: 現時点のMinibankにはDocker構成は確認できない。

Docker Imagecontainerの読取専用template

Dockerfileなどからbuildし、containerを起動する元になるartifact。

Minibankでの例: 導入する場合はregistryでversionと脆弱性を管理する。

CI/CD変更を継続的に検査・配布

変更の統合、build、test、安全なdeliveryまたはdeploymentを自動化する。

Minibankでの例: 型検査、回帰test、build、承認、監視をつなぐ。

SASTsource codeのsecurity検査

applicationを実行せず、codeから危険なpatternを探す。

Minibankでの例: 認証・入力処理の疑わしい実装を継続検査する。

DAST動作中applicationのsecurity検査

外部からrequestを送り、実際の応答や設定の弱点を探す。

Minibankでの例: APIの認証・認可や入力処理を攻撃者目線で試す。

SCA依存部品の検査

利用しているpackageと既知脆弱性・license・更新状態を調べる。

Minibankでの例: package-lock.jsonを基に依存riskを確認する。

Monitoring異常を継続的に見張る

重要指標を測定し、対応が必要な状態を担当者へ通知する。

Minibankでの例: 振込失敗率、lock待ち、照合issue、audit異常を監視する。

Git分散version管理system

fileのsnapshotとbranchを使い、変更履歴を共同で管理する。

Minibankでの例: source codeとmigrationをcommit・reviewする。

Infrastructure as Codeinfra設定をcodeで管理

cloudやnetworkなどの構成を再現・review可能な定義として扱う。

Minibankでの例: 環境差と手作業変更を減らすため本番構成を定義する。

MigrationDB変更の履歴

schemaやfunctionの変更を順序付きSQLとして管理する。

Minibankでの例: supabase/migrationsの日時prefix付きSQL。

SchemaDB内の名前空間

tableやfunctionを責務・公開範囲でまとめる。

Minibankでの例: public、ledger、core、admin、audit、reconciliation、ops。

Posting（記帳）出来事を仕訳にして台帳へ書くこと

Business Eventを記帳ルールで借方・貸方の明細に変換し、台帳へ追記する処理。

Minibankでの例: v8の posting.post_event() が ledger.post_journal_entry() を通じて記帳する。

Business Event会計の元になる業務上の出来事

利息支払・手数料徴収など、何が起きたかを会計処理から独立して記録したもの。

Minibankでの例: posting.business_events。1イベントに1仕訳が対応し、追記専用。

Posting Rule（記帳ルール）出来事を仕訳に変換する決まり

どの勘定の借方・貸方にいくら記録するかを定めた版付きのルール。

Minibankでの例: accounting.rule_definitions / rule_lines。仕訳に適用ルールIDが固定される。

Correcting Entry（訂正仕訳）取消と正しい再記帳の組

誤った仕訳を消さずに取消仕訳で打ち消し、正しい内容で記帳し直すこと。

Minibankでの例: posting.correct_event()。元・取消・訂正の3件を連鎖として表示する。

Balance Reconstruction（残高再構築）記録から残高を計算し直す

仕訳明細だけから任意時点の残高を再計算し、保存済みの残高と比べること。

Minibankでの例: posting.recompute_balances(時点)。

Payment Gateway銀行から決済システムへの窓口

支払指図を電文にして決済システムへ送り、応答を受け取る仕組み。

Minibankでの例: v9の interbank.send() と interbank.messages（架空の電文）。

RESULT_UNKNOWN（結果不明）処理されたか分からない状態

応答がなく、相手側で処理されたかどうか確定できない状態。安易な再送は二重送金につながる。

Minibankでの例: v9では照会（interbank.inquire）で解消し、未着が2回確認されるまで再送できない（IB008）。

End-to-End ID支払を端から端まで識別する番号

送金人から受取人まで同じ支払を指す識別子。再送時の重複判定に使う。

Minibankでの例: interbank.payments.end_to_end_id。決済システムSimulatorはこの番号で重複を排除する。

仕向・被仕向送る側の銀行と受ける側の銀行

送金を依頼された銀行を仕向銀行、受取人の口座がある銀行を被仕向銀行と呼ぶ。

Minibankでの例: v9では OUTBOUND（仕向）と INBOUND（被仕向）。

Return（返却）決済後に資金が戻ること

受取口座の解約などで入金できず、受取銀行が資金を送り返すこと。

Minibankでの例: v9の INTERBANK_RETURN_RECEIVED。状態は RETURNED。

Chart of Accounts（勘定科目表）決算書に使う科目の一覧

細かい勘定を、報告に使う科目（資産・負債・純資産・収益・費用）へまとめる対応表。

Minibankでの例: v10の gl.accounts と gl.account_map。顧客ごとの預金勘定はすべて 2100 普通預金に集計する。

Suspense Account（仮受金）入金先不明のお金の一時置き場

資金は受け取ったが誰の預金か特定できない入金を一時的に計上する負債勘定。

Minibankでの例: v10の 2900 仮受金と gl.suspense_items。特定後に SUSPENSE_CLEAR で顧客へ振替。

Daily Close（日次締め）その日の数字を検査して確定する

試算表・補助元帳などを検査し、正しければ締め記録を残す日々の手続き。

Minibankでの例: v10の gl.daily_close()。阻止検査が1つでも失敗すると BLOCKED。

Net Interest Income（資金利益）受取利息−支払利息

預金などで調達した資金を運用して得る利息収入から、支払う利息を差し引いた利益。

Minibankでの例: v10の 4100 資金運用収益と 5100 資金調達費用の差。

AML（マネー・ローンダリング対策）犯罪収益の移転を防ぐ取り組み

犯罪で得た資金の出どころを隠す行為を見つけ、確認し、必要に応じて報告する銀行の取り組み。

Minibankでの例: v11は架空データだけのSimulator。当局への報告は実装しない。

Transaction Monitoring（取引モニタリング）取引から兆候を探す継続的な検査

ルールやモデルで取引を調べ、人が確認すべき兆候をアラートにする仕組み。

Minibankでの例: v11の aml.scan()。台帳上の顧客取引を監視する。

Alert（アラート）確認すべき兆候

監視で見つかった、人が確認すべき取引の兆候。不正や犯罪の断定ではない。

Minibankでの例: v11の aml.alerts。口座や記帳は変更しない。

False Positive（誤検知）問題のない取引の検知

監視が兆候とみなしたが、調査の結果、正当な取引だったもの。

Minibankでの例: v11の判断 FALSE_POSITIVE。

Escalation（上申）判断を上位へ引き継ぐ

担当者だけで結論を出さず、より権限のある人・部署へ判断を委ねること。

Minibankでの例: v11では ESCALATED のケースを管理責任者だけが完了できる。

Risk-based Approach（リスクベース・アプローチ）リスクに応じて確認の深さを変える

すべてを同じ強さで調べず、リスクの高いものに資源を集中する考え方。

Minibankでの例: v11ではルールの重要度とアラートのスコアで表す。

Exception Management（例外管理）通常の流れから外れた項目の管理

結果不明・失敗・差異など、通常処理で完結しなかった項目を一覧化し、担当と手順で解消すること。

Minibankでの例: v12の Exception キュー（opscenter.items）。

Incident（インシデント）業務やシステムに影響する出来事

影響を記録し、原因を特定し、復旧と再発防止を行う対象となる出来事。

Minibankでの例: v12の opscenter.incidents。OPEN→INVESTIGATING→RESOLVED→CLOSED。

SLA対応の目標時間

サービスや対応について合意・設定した目標水準。ここでは解決までの目標時間。

Minibankでの例: v12ではSEV1=60分、SEV2=240分、SEV3=1440分。

Runbook（手順書）決まった状況の対応手順

特定の症状や作業について、確認と操作の順番・禁止事項をまとめた手順書。

Minibankでの例: v12の RUNBOOKS（キュー項目ごと）。

Business Date（営業日）業務上の日付

取引や締めをどの日の業務として扱うかを表す日付。暦の日付とずれることがある。

Minibankでの例: v7の ops.business_day_state。OPEN以外では金融操作が BD001 で止まる。

EOD / BOD日の終わりと始まりの処理

End of Day（締め処理）と Beginning of Day（翌日の開始処理）。

Minibankでの例: v7の営業日管理。開始者と別の管理責任者が締め・翌日オープンを行う。

Treasury（市場・資金部門）銀行自身の資金繰りと調達・運用

日々の資金繰りと、市場での資金の調達・運用を担う機能。

Minibankでの例: v13の Treasury・ALM 画面。資金取引は TREASURY_BORROW などで記帳する。

Funding Gap（資金ギャップ）期間ごとの資産−負債

満期の期間ごとに入ってくる資金と出ていく可能性のある資金の差。累積で見ると資金不足の時期が分かる。

Minibankでの例: v13の treasury.maturity_ladder()。

Core Deposit（コア預金）長く留まると仮定する預金

いつでも引き出せる預金のうち、実際には長期間留まると見込む部分。推計に基づく仮定。

Minibankでの例: v13では普通預金の70%（treasury.policy、教育用の仮定）。

Rate Shock（金利ショック）金利を一定幅動かす試算

金利が一定幅変化したと仮定して、利益や価値への影響を見る分析。

Minibankでの例: v13の rate_shock_bps。1年分の資金利益だけを概算する。

Deposit Beta（預金ベータ）預金金利の追随度

市場金利の変化のうち、預金金利に反映される割合。

Minibankでの例: v13では0.3（treasury.policy）。

Loan Disbursement（融資実行）貸付金と預金を同時に計上すること

融資の申込や承認では資金を動かさず、実行の瞬間に銀行の資産（貸付金）と顧客の預金（負債）を同じ額だけ計上する処理。

Minibankでの例: v14の lending.disburse と LOAN_DISBURSEMENT。承認の有効性と担当者の権限を実行の直前に再確認する。

Maker / Checker（提案者と決裁者）提案する人と決裁する人を分ける

1人の誤りや不正で重要な処理が実行されないよう、提案と決裁を別の人が行う職務分離の仕組み。

Minibankでの例: v14の lending.propose と lending.decide。同じ人が決裁しようとすると LN013。

Accrued Interest（未収利息）発生したが、まだ受け取っていない利息

利息を受け取る権利を、受け取る前から収益として正しい期間に計上するための資産勘定。

Minibankでの例: v14の LOAN_ACCRUED_INTEREST（GL 1400）。返済のときに元金とあわせて充当する。

Delinquency（延滞）約定日を過ぎても返済されていない状態

約定日の翌日から延滞とし、日数が進むと管理と対応の強さを上げていく。

Minibankでの例: v14の lending.aging。約定日の翌日から OVERDUE、30日で DEFAULT_CANDIDATE。

Default Classification（デフォルト分類）長期延滞を内部で確定する分類

長く返済されない債権を、人の確認を経て内部の区分として確定し、利息の発生などの扱いを切り替えること。

Minibankでの例: v14の DEFAULT_CONFIRMED。学習用の内部分類で、実際の信用情報には連携しない。

Price Version（価格の版）ある期間に有効な金利・手数料の一式

提案と別人の承認を経て、未来の営業日から有効になる価格の記録。発行後は書き換えず、新しい版で置き換える。

Minibankでの例: v15の pricing.product_versions。既存契約は契約時の条件のまま。

Contract Snapshot（契約時の固定）契約を結んだ時点の条件を契約に写すこと

価格表があとから変わっても、契約の利息を契約自身の条件で再計算できるようにする。

Minibankでの例: v15では time_deposits に年利・中途解約の利率・版IDを保存する。

Quote（見積り）条件を示すが、約束はしない提示

元本・期間から利息などを示す。有効期限を過ぎたり、版が切り替わったりしたときは契約しない。

Minibankでの例: v15の pricing.quotes。発行の翌営業日まで。

Legacy Contract（従来の契約）新しい仕組みの前に結ばれた契約

後から条件を推測して書き換えず、当時の規則のまま扱い続ける契約。

Minibankでの例: v15より前の定期預金。pricing_version_id が空。

Day Count（日数計算）利息の日数の数え方

何日分の利息かを決める規則。MiniBankは実際の暦日数を365で割る。

Minibankでの例: v15の pricing.simple_interest。1円未満は切り捨て。

OAuth（認可コード方式）パスワードを渡さずに権限を委ねる仕組み

顧客の同意にもとづき、範囲と期間を限ったトークンを第三者に渡す。学習用の簡易版で、実在の認可サーバーの準拠を示すものではない。

Minibankでの例: v16の public.ob_token。認可コードは60秒・1回限り、トークンは15分。

PKCE認可コードの盗用を防ぐ追加の証明

アプリが毎回作る検証子のハッシュを先に渡し、交換時に検証子そのものを示させる。コードを盗んでも交換できない。

Minibankでの例: v16はS256のみ。plainは受け付けない。

Consent（同意）顧客が範囲と期間を許した記録

許可の証拠であり、いつでも取り消せる。取り消した瞬間に、関連するトークンが使えなくなる。

Minibankでの例: v16の openbanking.consents。30日間、次の呼び出しから即時に失効。

Scope（範囲）トークンで許される操作の種類

必要な操作だけを許して被害を小さくする。範囲が足りなければ拒否する。

Minibankでの例: v16の accounts.read・balances.read・transactions.read・transfers.write。

Outbox状態の変更と同時に通知の元を残す設計

変更と通知の元を同じトランザクションに置き、片方だけ成功する食い違いを防ぐ。配信は別に、何度でもやり直せる。

Minibankでの例: v16の openbanking.events。同意ごとに欠番のない連番。

RTO／RPO復旧までの時間／失ってよいデータの範囲

障害のあとに、どれだけ早く戻れるか、どこまで前の状態に戻ってよいかを表す。条件つきの測定値で、目標や保証ではない。

Minibankでの例: v17では演習で測り、条件と一緒に recovery.drills に残す。

Fencing（書込停止）古い側や別の処理が書けないようにすること

復旧の間に二重に書かれるのを防ぐ。書込世代（epoch）で、古い設定の書き手を見分ける。

Minibankでの例: v17の ops.require_business_day_open に足した検査（RY001／RY002）。

Manifest（バックアップの記録）バックアップ時点のデータの指紋

復元後に、バックアップ時点と同じかを数値で確かめる。

Minibankでの例: v17の recovery.manifests。件数・最終仕訳・試算表と残高のハッシュ・営業日。Freeze Hardening で、グループの勘定残高・移動の状態、同意・融資・定期預金の状態のハッシュを追加（digest の方式 2）。digest 版 3 で、書込停止中は変わらない状態の行ごとのハッシュを追加（現行。融資（契約・返済予定・申込・分類と審査のイベント・命令・商品の版）、預金の価格（手数料と利息の実行・その訂正・商品の版）、法人（支払依頼・支払予定・メンバー・組織・設定依頼）、group（事業体・事業体の役割）、Open Banking（クライアント・同意・振込依頼・通知先の登録）、顧客の振込依頼、risk の設定（パラメータ・シナリオ・測定）、twin の設定（モデル・シナリオ）、銀行間送金（支払・決済バッチ）、管理責任者の復旧の記録と方針、締め処理の実行、KYC の状態）。運用者の権限は digest に入れず、運用者の一覧を外に控えて渡せば、一方向の検査（権限が増えた向きだけ NG）が走る。一覧を渡さなければ検査は走らず、検証に「検査せず」と出る。AML など digest に入らない状態は、人が確認する。

Postmortem（事後検証）何が起き、なぜ起き、何を直すかの記録

責める記録ではなく、次に活かすための記録。

Minibankでの例: v17の recovery.postmortems。追記専用。

Expected Loss（期待損失）返ってこない可能性を金額にしたもの

EAD × PD × LGD。区分ごとに計算し、合計する。

Minibankでの例: v18の risk.credit_calc。PD・LGDは架空の仮定。

Stress Test（ストレステスト）「もし〜なら」の試算

基準と並べて、悪化の大きさを見る。予測ではない。

Minibankでの例: v18のシナリオ（金利＋1%、預金流出20%、信用ストレス、複合）。

Risk Snapshot（リスクの入力の凍結）ある時点の入力を凍結した記録

同じ入力から、何度でも同じ結果を再現できるようにする。

Minibankでの例: v18の risk.snapshots。入力ハッシュつきで追記専用。

Intercompany（相互勘定）グループ内の貸し借り・手数料を、両側の帳簿に載せたもの

貸した側は債権、借りた側は債務。連結では差し引く。両側が一致していることを照合する。

Minibankでの例: v19の1500と2500、4300と5400。移動中の分は説明がつく差として分ける。

Consolidation（連結）グループ全体の数字を合算して見ること

各法人の試算表を合算し、グループ内の貸し借りを差し引く。報告のための計算で、各法人の帳簿は変えない。

Minibankでの例: v19の bankgroup.consolidate。確定したスナップショットだけから作る。

Elimination（消去）連結上でグループ内の取引を差し引くこと

債権と債務の小さい方だけを差し引き、残りは理由つきで残す。

Minibankでの例: v19では元帳に仕訳を入れず、連結の結果の中だけで示す。

Digital Twin（デジタルツイン）実績を写し取った、別の試算用の模型

実績を凍結し、明示した仮定を掛けて将来の数字を試算する。予測であって実績ではなく、正本には書き込まない。

Minibankでの例: v20の twin スキーマ。同じ入力・モデルの版・シード値で再現できる。

Baseline（ベースライン）試算の出発点として凍結した実績

ある時点の試算表・Treasury・価格・融資を写し取り、入力ハッシュを付けて追記専用に残す。

Minibankでの例: v20の twin.baselines。

Seed（シード値）乱数の出発点となる数

同じシード値なら同じ乱数の列になり、揺らぎを含む試算でも結果を再現できる。

Minibankでの例: v20の twin.rand。預金の月次の揺れに使う。

Sensitivity（感応度）仮定を少し動かしたときの結果の変化

結果がどの仮定に頼っているかを知る。正しい値を推定するものではない。

Minibankでの例: v20の twin.sensitivity。各パラメータを20%動かす。

Traceability（追跡可能性）結果から原因までたどれること

残高や仕訳から、元になった出来事・適用ルール・操作者・監査ログまで遡れる性質。

Minibankでの例: 管理画面のイベントトレース（/admin/ledger/events/[id]）。