Coinbase Irelandの資金保護問題：計算から落ちる入金をどう見つけるか

01

公表された処分から、日々の入金計算を問う

アイルランド中央銀行は10月22日、Coinbase Ireland Limited（CBIE）の電子マネー資金保護違反に関する21日付の和解を公表した。けん責と325万2618ユーロの制裁金の発効には、高等法院の確認が必要だ。このニュースを読むうえで役立つ問いは、「銀行にいくらあるか」を確かめる前に、比較相手となる保護対象額へ、どの入金が入ったのかということだ。 ［処分公表］

保護対象額は、銀行画面にそのまま現れる単一の数字とは限らない。入金の記録を集め、受け取った資金の性質を確かめ、必要な残高へ反映する。その途中で一件が消えれば、最終表の足し算が正確でも、必要額は小さくなる。反対に同じ一件が二度現れれば、必要額が膨らむ。利用者が見る入金履歴と、事業者が使う日次計算の間には、このように複数の処理が入り得る。

本文の四件の架空入金を使うと、その違いを紙の上でも検算できる。取引の識別番号を追いながら、対象からの脱落、照合後の重複、別の入金による誤差の相殺を一つずつ発生させる。最後に見るのは、正解の合計だけではない。どの識別番号が一回ずつ残るべきかを比べる。読者自身の資金保護状況を認定する表ではないが、事業者の説明に残る問いを具体化できる。

残高の数字から、数字を作った入金へ戻る

顧客が通常受け取る説明は、「資金を分別している」「日次で照合している」といった手続きの概要だろう。その説明からは、顧客番号を照合できない入金が日次計算のどこへ流れるのかまでは分からない。そこで尋ねる対象を絞る。入金が顧客画面に反映されるまでの間、何を根拠に対象へ加え、どこに未解決の記録を残すのか。これなら、単なる安心の表現と計算の説明を比べられる。

この問題は利用者の確認だけで終わらない。決済サービスを利用する企業には、入金の照合が遅れれば、販売代金の確認や返金の判断に追加の作業が生じる可能性がある。サービス事業者には、例外を調べる人員と、必要な資金を置く費用がかかる。海外拠点や取引通貨が増える場合も、取引量と同じ速さで正しい対象一覧を作れるかが、拡大に伴う運営費用を左右する。例えば、販売企業が入金番号と請求書を自動で突き合わせる場合、事業者側の照合未了がいつ解消したかによって、企業側で再処理する明細の数も変わる。

ただし、この一件から暗号資産全体の価格や、特定の会社の現在の出金能力を推定することはできない。資金保護の計算に関する処分と、トークンの市場価格には別の根拠が必要だからだ。ここで確かめるのは、入金記録から日次の比較額へ到達する経路である。少数の記録でも誤りの形を説明できれば、大きな総額の公表だけでは見えにくい、計算の弱点を読み取る助けになる。

02

SG Groupの見方：保護対象額は入金の選び方から生まれる

残高を比較する作業には、少なくとも二つの数字が必要になる。一つは、適用される条件に従って保護すべき資金の額。もう一つは、その目的に使えるものとして確認された資金の額だ。前者を作る入金一覧が不完全なら、後者の銀行残高を精密に取得しても比較は直らない。計算の出発点を入金へ戻す理由は、照合の頻度を増やすだけでは修正できない誤りを見つけるためである。

ここでいう「対象一覧」は、同じ条件で集計する取引の集まりを指す。銀行から取得したすべての明細を、そのまま一つの合計へ足すこととも違う。資金の受領目的、対象となる法人、受領した時点、取消しや返金の状態などを確かめ、該当する取引を選ぶ必要がある。条件が決まった後は、選んだ理由と外した理由を取引番号へ結び付ける。金額だけでは選び方を再現できないからだ。

保護に必要な額を誤って小さく算出すると、その誤った数字だけを見た担当者には、資金を十分に確保したように見える可能性がある。反対に必要額を大きく算出すれば、追加の資金移動を要すると判断するかもしれない。これは計算の誤りが意思決定へ伝わる経路の説明であり、今回の事業者がそのような資金移動を行ったという意味ではない。実際の影響には、別の統制が誤りを止めたかも関わる。

対象額が動くと、使える資金の見え方も変わる

サービスの運営資金を考える際にも、計算した必要額と会社が自由に使える現金を直結させるべきではない。銀行口座に資金があっても、利用条件や処理中の送金が残る場合がある。逆に、計算の誤りを直して必要額が減ったからといって、その差額を直ちに経費へ使えるとは限らない。入金一覧の修正は、支払いの許可とは別の段階であり、会計上の利益を生む操作でもない。

事業の採算に届く経路は、架空の差額を利益へ換算するより、作業と資金の使い道で考える方が明確だ。例外の調査に時間がかかるほど、確認担当者の負担が増え、利用者への回答も遅れ得る。過大な対象額に合わせて資金を余分に置けば、他の用途に回せない期間が生まれる。ただし、その費用の大小は金利、契約、調査の所要時間で変わり、公表された不足額だけから算出できない。費用を比較するなら、未解決件数、解消までの時間、修正後に同じ入金を再処理した回数など、作業の発生源へ結び付く情報が手掛かりになる。

拡大する決済サービスを比較するなら、処理件数の多さだけでなく、例外が増えたときの計算方法を尋ねたい。一覧へ残すべき入金が残り、重複が増えず、判断待ちの資金に調査先が付いているか。こうした手順が安定していれば、取引増加のたびに手作業で総額を合わせる負担を抑えられる可能性がある。反対に、最終残高へ調整額を足すだけでは、次の入金で同じ問題が再び生まれ得る。

事業者の説明を契約条件へ戻す基礎は、取引所の契約・保管・出金条件を確認するで補える。入金の検算とは別に、出金の条件も読む。

03

二つの数値から、何が分かり、何が分からないか

和解通知が説明する過去の計算上の誤りには、入力時点のずれと未割当資金の脱落がある。実現した消費者被害の証拠はないとされる。 ［和解通知］

後の架空例では、顧客番号を結び付けられない入金にも、受領目的を示す別の証拠があると設定する。顧客の特定が済まないことと、どの業務のために受け取った資金か不明なことは、別の問いだ。一つの欄名だけで全件を含めたり外したりすれば、この二つをまとめてしまう。顧客との照合結果と、対象へ含める根拠を分けて残すと、その判断を後からたどれる。

計算の締め時刻にも、記録が抜ける入口がある。銀行の入金一覧と顧客残高の一覧を異なる時点で作れば、後から受け取った入金に対応する顧客記録がまだ存在しないことがある。そこで一致する行だけを残す処理をすると、時点の差が入金の脱落へ変わる。後日、顧客番号が付いて合計が直っても、その日の計算がどの記録を落としたかを消してしまえば、問題の発生地点が分からなくなる。

大きさを示す数字と、日々の経路を分ける

最大値から平均や発生日数は求められず、翌日の回復までの時間も分からない。大きさを一つの値で比べるときは、その値がどの問いへ答えるのかを先に確かめたい。例えば、日々の資金移動の履歴を再現したければ、一日の不足を表す二つの数値だけでは足りない。対象日の明細や、増減が生じた時刻の記録が必要になる。数字が精密に表示されていることと、必要な範囲を測っていることは異なる。

以下の照合ミスは、CBIEの特定の内部処理を再現したものではない。架空例が明らかにするのは、記録を組み合わせる規則によって結果がどう変わるかという算術だ。実際の原因や影響の大きさを評価するには、対象期間の記録、計算の仕様、修正の経過などとの照合が必要になる。例の数字が一致しても、実際の取引で同じ順序や条件が使われたと推定してはいけない。

是正の説明を評価する際には、以前の計算を何に置き換えたかが手掛かりになる。顧客を特定できない対象入金を別経路で残せるようにしたのか、元の明細と出力の件数を追えるようにしたのか。その答えは、例外の記録が次の日へどのように引き継がれるかにも現れる。処分の額だけで運営の品質を順位付けするより、抜けた入金を再び落とさない仕組みを説明できるかを読む方が、今回の問題に近い。

04

四件の架空入金から、正しい対象を作る

図2は、同じ締め時刻までに銀行へ入った四件の記録である。D1は顧客Aから100ユーロ、D2はBから60ユーロ、D3は顧客照合が未完了のUから20ユーロ、D4はGから20ユーロとする。合計は200ユーロだ。すべて説明用に作った金額と識別番号で、実際のCBIEの取引ではない。返金、手数料、為替換算、前日からの残高を入れず、四件から対象額を作る部分だけを切り出している。

対応表では、AとBはCBIE、Gは同じグループの別法人に属するものとする。Uは通常の顧客番号と照合できない。ただしD3については、CBIEの電子マネーのために受領した資金であることが、顧客番号とは別の証拠で確認されていると仮定する。この受領目的と対象性が前提だ。単に送金人の名前が分からないという理由だけで、未特定入金のすべてをCBIEの計算へ加える例ではない。

この条件なら、CBIEの対象はD1、D2、D3の三件となり、100＋60＋20で180ユーロになる。D4は入金の存在を消すのではなく、別法人に属する記録としてCBIEの対象から外す。ここでは、対象外という判断と、銀行に入金がなかったという判断が違う。元の四件を残したまま三件を選べば、グループ全体の受領額とCBIEの対象額の差を、一件の記録まで戻って説明できる。

顧客番号がなくても、受領目的の根拠は残せる

D3の例外台帳には、元の銀行明細の識別番号、受領目的の根拠、顧客照合が未完了である理由を結び付けるとよい。後から顧客が判明しても、最初の入金が別の新規入金へ変わるわけではない。通常の顧客一覧へ移す際は、例外側を残したまま二度足さないよう、元の番号を引き継ぐ。実際の業務で受領目的を証明する資料や判断権限は契約と適用条件に応じて定める必要があり、表の文字だけでは代替できない。とりわけ後から追記した説明は、受領時から存在した証拠と分けて保存したい。判断の根拠が増えたことと、入金の受領日が変わったことを混同しないためだ。

集計に入る前に、各行の金額を一度ずつ読むことも、この小さな例では有効だ。同じ金額のD3とD4は、別の入金を表す。金額が等しいから片方を重複として消してはいけないし、顧客記号が違うから自動的に別の資金と判断するだけでも不十分だ。取引番号は、銀行から来た記録が後の処理で何行へ増え、どこで外れたかを追うために使う。表示用の顧客名とは役割が違う。

読者は、まず四行を手元へ書き写し、「CBIE対象」の印を三行だけに付けてから、金額を足してみるとよい。その後の三つの誤りは、毎回この元の四行へ戻して比較する。一つの誤りを直さないまま次を重ねると、どの変更で合計が動いたか分からなくなる。なお、この表は必要額の生成だけを示しており、資金保護の条件を満たす口座残高を与えていない。180ユーロという答えだけでは不足の有無までは決まらない。

05

照合できた行だけを残すと、20ユーロが消える

最初の誤りは、入金一覧と顧客対応表を組み合わせる際、一致する顧客が見つかった行だけを残すことで起きる。この組み合わせ方は、データ処理では内部結合と呼ばれる。D1とD2は顧客を照合できるため残る。D3には一致する顧客行がないため、対象性を示す別の証拠があっても出力から外れる。D4は照合できても別法人なので除かれる。結果は二件、160ユーロとなる。

この結果を見て、160ユーロの足し算が正しいかだけを調べても、誤りは見つからない。残った二行の金額には問題がないからだ。元の対象三件と出力二件の間を照合し、D3という番号が消えた場所を探す必要がある。銀行明細から最終一覧へたどる方向の検査は、「出力された行は正しい」という検査を補う。出力に存在しない記録を、出力だけから拾い上げることはできない。外した理由が正当なら、その理由を示せばよい。しかし、対象性が確認されたD3が、顧客照合に失敗したことだけを理由に消えたなら、計算経路の修正が必要になる。

直すときは、通常の顧客照合で選んだD1とD2へ、別途対象性を確かめたD3を例外経路から一度だけ加える。これで三件の180ユーロへ戻る。D3の顧客欄を便宜的にAへ書き換える必要はない。そのような書き換えは合計を直しても、誰の入金かという未解決事項を見えなくする。顧客の特定が済んでいない状態と、資金を対象へ含める判断を、同じ欄の値で無理に表そうとしないことが肝心だ。

未照合のまま残す経路を、通常処理へつなぐ

例外経路を付ける際にも、通常経路との重なりを調べる必要がある。例えば翌日にD3の顧客が判明したなら、同じ入金が通常経路へ入る可能性がある。例外台帳側の記録を出力へ加え続ければ、今度は脱落が重複へ変わる。そこで、例外を終了した時点と、通常処理へ渡した取引番号を残す。調査の完了という作業上の状態を、元の資金が二度発生したことと取り違えないためである。

「銀行の全入金を足せば脱落はなくなる」という修正も、この例では正解にならない。D4まで含めれば、CBIEに属さない20ユーロが加わる。必要なのは、顧客対応表を使うか使わないかという二者択一ではなく、対象性の根拠を保ったまま照合未了の行を通す経路である。D3が実際には別目的の資金だと分かれば、その証拠に従って対象を変える必要がある。例外の記録は、無条件の算入を続ける口実にはならない。

図3の流れを使うと、どこで二つの判断が分かれるかが分かる。まず入金の存在と対象性を確かめ、その後で顧客を照合する。顧客が見つからなければ、対象性をすでに確認した入金を例外台帳へ回し、通常分と一度ずつ合計する。最後に初めて、別途確認した保護用資金と比較する。この順序は実際の規制適合を自動判定するものではなく、例のD3を消さずに残すための計算経路を示している。

06

対応表が二行あると、一件の入金が二度足される

二つ目の誤りを調べる前に、元の四件へ戻る。今度はD3を例外経路で正しく含め、D4は対象外のままとする。変更するのはAの対応表だけだ。本来一つの有効な対応があるべきところに、有効期間の重なった二行があり、両方とも同じ締め時刻の照合対象になると仮定する。顧客が二人に増えたわけでも、入金がもう一件あったわけでもない。一つの入金に、対応表の二行がそれぞれ結び付いてしまう。

するとD1の100ユーロは、照合後の一覧へ二回現れる。D2の60ユーロとD3の20ユーロは一回ずつ残るため、合計は100＋100＋60＋20で280ユーロになる。正しい対象額との差は、二重に現れたD1の一回分だ。この誤りでは、元の銀行明細も、各入金の金額も変わらない。照合によって行が増える段階を見落とすと、「銀行データから作った数字だから正確だ」と考えながら、実際の入金より多く足してしまう。

出力には四行あるが、異なる元の入金番号は三つしかない。この違いが調べる入口になる。D1という番号に何行が結び付いたかを数え、その理由を対応表へ戻って確かめる。単に件数が増えたことを不正と決め付けるのではない。実務には一件を明細へ分割する正当な処理もあり得るため、元の金額をどのように配分したかまで確かめる。この架空例では配分をせず全額を二行へ載せたため、合計が膨らんでいる。分割した各行を足すと元の入金額へ戻るか、同じ元明細へ全額が繰り返し付いていないかを調べれば、正当な内訳と単純な複製を見分けやすくなる。

金額の重複ではなく、入金番号の増殖を調べる

修正を金額だけで行うと、別の誤りが生まれる。等しい金額を一つにまとめる方法では、たまたま同額の別入金まで落とす可能性がある。顧客ごとに最初の一行だけを残す方法でも、同じ顧客の正当な複数回入金を消し得る。比較するのは、元の入金番号と、その入金に属する額の合計だ。今回ならD1の二行が、元の100ユーロを超えて計上していることを確かめ、原因となる対応の重なりを直す必要がある。

対応表の新しい日付の行を機械的に選ぶだけでも、根拠が不足することがある。その日付が登録日なのか、実際に適用する日なのかによって、選ぶ行が変わるからだ。正しい対応が確定できなければ、曖昧さを記録して調査へ回し、対象性が確認できている入金自体を消さずに保持する経路を設ける。こうして、対応表の判断待ちと、元の入金が存在することを切り離す。例外経路を使う場合にも、通常経路との二重計上を同時に防ぐ必要がある。

過大な計算が資金移動の判断へ使われれば、事業者は不要な追加資金を置こうとするかもしれない。その間の資金繰り負担や、原因を調べる作業は経済的な費用になり得る。ただし、計算が大きく出たこと自体は、実際に余分な現金を移した証拠ではない。承認前の検査で止まれば、影響は修正作業にとどまる。このため、重複を見つけた後は、誤った一覧がどの判断に使われたかをたどることが、費用の評価につながる。

07

脱落と誤算入が相殺すると、180ユーロでも不正確になる

三つ目も元の四件から始める。D1とD2は一回ずつ残す一方、D3を落とし、代わりに別法人のD4を誤って含めるとする。すると計算は100＋60＋20となり、正しい場合と同じ180ユーロになる。誤って外れた額と誤って入った額が等しいためだ。Aの対応表は一行に戻しており、前節の二重計上は含めていない。これで、合計の一致がどこまで誤りを見逃すかを、他の誤りから切り離して確かめられる。

この出力は三行で、入金番号の重複もない。したがって、合計、件数、番号の一意性という三つの検査を、それぞれ単独で通ってしまう。違いを見つけるには、正しく選んだ番号の集合と、実際に出力された番号の集合を比べる。前者にだけあるD3は欠落、後者にだけあるD4は予期しない算入となる。合計値に加えて、一件ずつの所属を確かめる検査が必要になる理由を、この入れ替わりが示している。

仮に比較相手の資金額まで180ユーロだったとしても、そこから計算全体が正しいとは結論できない。どの入金から必要額を作ったかという誤りは、そのまま残るからだ。一方、この誤算入だけを根拠に、顧客へ20ユーロの損失が生じたと主張することもできない。資金の実際の所在、保護に使える条件、受払いや回収の経過は、この表に与えていない。算術の一致と、顧客の権利や回収結果には、それぞれ必要な証拠がある。

同じ合計を作る、違う三件

差額を一つの欄だけで報告すると、この二方向の誤りはゼロへ縮んで見える。そこで、欠落した取引と余分に入った取引を別々に残す。D3を追加する修正とD4を外す修正は、合計への影響が逆でも、別の理由を持つ操作だ。片方だけを実施すれば、今度は総額も変わる。金額が動かないから修正不要と判断したり、正しい総額へ調整する一行だけを加えたりすると、誤った入金一覧は保存され続けてしまう。

こうした入れ替わりは、利用者別の記録を後から調べる際にも負担を生む。総額の帳尻が合っているので、日次報告からは調査を始めにくい。問い合わせを受けて元の入金へ戻ったとき、計算へ渡した番号が残っていなければ、どの時点で外れたかを再構成しなければならない。必要なのは、顧客の秘密情報を公表することではない。事業者の内部で、元の明細と計算結果を対応付けられる粒度を失わずに保つことである。対応を再構成する時間が長くなれば、利用者へ理由を説明するまでの時間も延び得る。総額が合う段階で記録を捨てる判断には、後の問い合わせ対応という費用も伴う。

三つの誤りを比べると、確認の役割を分担できる。元の入金から出力へ追う検査は脱落を探し、同じ入金番号に結び付く額の検査は重複を探し、対象番号同士の比較は入れ替わりを探す。どれか一つで残りを代用することはできない。四行の例を使い、誤りを加える前後でどの検査が反応するかを読者自身が確かめれば、「照合している」という説明の中で、何を照合しているのかを、より具体的に尋ねられる。

暗号資産の保有者と償還主体という別の分類は、保有者と償還を受け付ける法人を照合するで比べられる。電子マネーと同じ制度だとは扱わない。

08

同じ入金の更新を、新しい入金にしない

未割当入金D3に後から顧客番号が付いたとき、計算の対象額まで増えてよいのだろうか。この架空例では、D3の20ユーロは、顧客番号が不明でも別の資料によってCBIEの電子マネーに関する資金と分かっている。番号の補完は受取人を特定する作業であり、追加の入金ではない。D3を更新する前後で、対象となる入金の集合と180ユーロの合計が変わらないことが、最初の検査になる。

更新前のD3を版1、顧客番号を補ったD3を版2と呼ぶ。二つの行には、同じ銀行入金を指す共通の取引IDを残す。版2を採用する計算に版1まで足すと、口座には一度しか来ていない資金を二度数えてしまう。過去の版を保存することと、保存した全行を合算することは違う。検算用の表でも、取引ID、版番号、どの版を採用したかを横に書けば、更新履歴が増額へ化ける箇所を見つけやすい。

過去の日の計算を再現する場合も、現在の顧客名簿へ結び直すだけでは足りない。その日に使った入力と対応表を残し、当時の結果を再現したうえで、訂正後の結果との差を取引別に説明する。元の報告が180ユーロで、番号補完後も180ユーロなら金額は動かない。ただし、D3が未割当欄から顧客別欄へ移ったことは記録に残る。これなら、金額の変化がない修正も追跡できる。

取消と訂正を、元の取引へ戻して確かめる

D2の60ユーロに取消が生じたという追加の架空テストでは、元の行を黙って消さない。取消記録をD2へ結び付け、入金と同額の重複データなのか、実際の返金なのかを資料で確かめる。銀行から資金が出たことだけで、電子マネーに関する顧客への義務も消えたとは限らない。返金の相手や契約上の処理が異なれば、必要な残高の計算も異なるためだ。符号を逆にした行を置くだけでは、この判断は済まない。

取消が計算の締め切り後に成立したなら、締め切り前の180ユーロをそのまま再現できるかを先に試す。次の計算で60ユーロを減らすテストは、その資金に対応する義務も減ったという証拠を追加した別の状態で行う。この条件を満たす架空例なら120ユーロとなる。後から分かった出来事を過去へ差し込むと、当時の不足や誤算が見えなくなる。訂正版を作る場合も、元の結果と変更理由を並べて残す方が検証しやすい。

この検査が役立つのは、同じ処理をもう一度動かした場合である。入力と採用する版が同じなら、D3が再び追加されたり、取消が二度適用されたりしてはならない。合計だけでなく、採用した取引IDと版の組を比較する。再実行のたびに結果が動くなら、計算の正しさを論じる前に、更新を受け取る処理を調べる必要がある。処理回数を増やすことでは解決せず、どの入金を一度だけ数えるかを固定する必要がある。

09

銀行側の記録から、件数と構成を検算する

対象額を計算した後は、それを裏付ける現金と照合する。ただし、同じ集計表から「必要額」と「保管額」の二つの欄を作り、その一致を見るだけでは独立した検算にならない。D3が最初の表から落ちれば、両方の欄が同じ誤りを引き継ぐためだ。銀行から得た明細や残高資料を別の入口にし、入金の存在、計算へ入った記録、必要な資金の置き場所を、それぞれの証拠から結び付ける必要がある。

架空例で期首残高も出金もゼロと追加で仮定すれば、CBIEに対応する三つの入金から180ユーロを計算できる。この場合でも、グループ全体の200ユーロを同じ残高と呼ぶことはできない。D4の20ユーロは別法人の資金という設定だからだ。実際の照合では、期首残高、返金、他口座への移動、手数料などの明細も要る。入金の合計とある時点の銀行残高を、条件をそろえず直接比較すると、正常な資金移動まで誤りに見える。

図の四つの金額は、同じ架空の入金と同じ締め切りを使った別々の計算状態である。脱落、重複、誤った置き換えを一度に重ねた値ではない。合計が小さい場合は脱落を、大きい場合は重複を疑う手掛かりになるが、180ユーロという正解と同額でも構成を再確認する。正解の数字を覚えるより、D1、D2、D3が一度ずつ含まれ、D4が除かれる理由を一行ずつ説明する方が、別の金額にも応用できる。

同額の別の入金に置き換わる誤りを探す

検算の結果は、合計差だけでなく、対象のまま抜けた取引、対象外なのに入った取引、複数回入った取引に分けて残す。ここで「分からない」を無理にどちらかへ割り当てると、見栄えのよい一致ができてしまう。根拠が未確定の記録は件数と金額を別に示し、その判断が変われば対象額がどちらへ動くかを計算する。D3のように所属する資金の種類は分かり、顧客番号だけ不明な状態と、所属自体が不明な状態も混ぜない。

この方法の限界は、銀行明細だけでは顧客への義務の全体が分からないことである。明細は入出金の証拠となるが、発行済み電子マネー、未処理の償還、記帳前の取引まで自動で説明してくれるわけではない。顧客側の記録や決済の状態と照合して初めて、差の理由を絞れる。複数の資料が同じ入力の写しにすぎない場合も、証拠が増えたと考えず、元の記録まで戻って確かめたい。

10

対応表の変更を、通る例と止まる例で試す

顧客番号と法人を結び付ける対応表を直す場合、修正対象の入金だけが正しくなるかを見る検査では狭過ぎる。AとBがCBIE、Gが別法人という架空の対応表を固定し、修正後に通るべき例と、除かれるべき例を一緒に用意する。D3の顧客番号を補う正例では、既に対象だった資金が残る。一方、Gを参照するD4は、処理を変えても対象に入らない。片側だけを試すと、全件を含める乱暴な修正でも合格してしまう。

Aに対応する行が二つできたテストでは、同じD1を二度足してはいけない。顧客番号を手掛かりに二つの候補が出たなら、どちらを採用する根拠があるかを解決するか、曖昧な対応として処理を止める。機械的に先頭の一行だけ採用する方法も、並び順が変われば結果が変わる危険がある。入金の取引IDが一つであることと、対応表の候補が一つであることを、別々に確かめる必要がある。

顧客番号が一致しなかった場合の扱いも試す。D3は独立した資料によって対象と分かるため、番号が見つからないことだけを理由に落としてはならない。しかし、この例を一般化して、参照先がない全入金をCBIEの電子マネー資金にするのも誤りである。期待する結果は、「未一致なら必ず含める」という単純な規則ではなく、資金の性質を示す別の根拠を処理へ反映できることである。その根拠がないテストも併せて置く。

変えていない取引まで動いていないか

新旧の対応表を比較するときは、合計差がゼロの取引も見たい。D3の顧客番号の補完なら、金額を変えずに未割当欄から顧客別欄へ移る。他方、別法人を示していたGがCBIEへ変われば、D4が計算へ混ざる可能性がある。変更を承認した記録だけでなく、なぜその資金の所属が変わるのかを示す資料が必要だ。名称の統一やデータ移行を理由に、過去から同じ法人の資金だったと自動で書き換えない。

図のテストには、行の並べ替えや同じデータの再取込みも含めた。顧客番号の補完のように結果の内訳が変わる操作と、順番だけが変わる操作を同じ検査にしないためである。前者は説明できる再分類、後者は合計と構成の不変が期待される。入力を一か所ずつ変えて比較すれば、問題が番号の対応、取引の重複、採用する版の選択のどこで生じるかを絞りやすい。多数の変更をまとめて試すと、原因同士が隠し合う。

実際の運用では、少数の例が通っただけで全取引の正しさを証明できない。少なくとも、新旧の処理で対象が変わった取引をすべて取り出し、変わる予定だったものと予定外のものへ分ける。その後、影響を受ける入金経路や顧客の種類を広げて検査する。特定の銀行や番号形式だけで成功するなら、同じ説明を他の経路へそのまま当てはめられない。検査範囲を広げる理由は取引量の大きさだけでなく、入口の違いにもある。

疑わしい取引の調査と報告の流れは、決済監視の入力・調査・報告をたどるで確認できる。資金額を作る計算と、報告義務の判断は分ける。

11

例外調査と償還：正しい集計だけでは終わらない作業

未割当の資金を調べる作業にも人手がかかる。D3のような記録なら、顧客番号を見つける前から対象額へ含め、その後に所属する顧客を確定する作業を分けられる。一方、資金の性質そのものが不明なら、判断に必要な資料を集める工程が増える。この二つを一つの「未処理件数」にまとめると、何を直せば作業が終わるのか分かりにくい。件数が減っても、単に計算の対象から外した結果なら処理の改善とはいえない。

処理の遅れから、何を推定できるか

顧客にとっては、残高表示があることと、正しい入金として照合が済んでいることの距離が問題になる。参照番号の調査が長引けば、返金先の確認や償還の手続きに追加のやり取りが要る可能性がある。ただし、本人確認や不正利用の調査など別の理由でも手続きは止まるため、出金の遅れを一件見ただけで資金保護の不足を推定することはできない。入金記録の誤りがどのサービス工程へ影響したかを特定する必要がある。

金融市場への意味も、この事業上の経路から考えるのが適切だ。正確な取引集計が、余分な送金、例外調査、資金不足への備えを減らすなら、同じサービスを支える費用は改善し得る。逆に、検査と再照合に追加投資が必要なら、短期には費用が増えることもある。今回の公表だけから、親会社の収益、顧客資金の流出、暗号資産の価格がどれほど動くかは導けない。手数料や市場価格への反映には、別の開示や観測が必要である。

12

小さな差額なら、検査を簡略にできるか

細かな入金を一件ずつ見るより、全体の差額に基準を設けて管理すべきだという反論には実務上の理由がある。すべての差を同じ手間で調べれば、顧客対応や大きな障害の処理へ割く人員が足りなくなるかもしれない。金額、滞留期間、発生頻度を使って調査の順番を決めることは合理的である。ただし、優先順位を付けることと、対象になる取引を最初から計算へ入れないことは、異なる判断になる。

平均的な差額が小さくても、特定の日や入金経路へ偏っていれば、影響を受ける顧客の経験は平均値から分からない。少額が広く分散する場合と、一つの大口入金が処理から落ちる場合でも、必要な対応は異なる。しかも、同額の誤った組入れがあれば差額は縮む。問題の大きさを調べる際には、差の絶対額に加えて、どの記録がどの方向へ誤ったかを残し、その集まり方を確かめる方が説明力がある。

もう一つの反論は、計算を各拠点へ分散させるほど、規則がばらばらになりやすいというものだ。共通の仕組みなら、入金の定義、重複の検出、訂正の方法をそろえられる。小規模な現地チームだけでは用意しにくい検査を、一括で実施できる利点もある。今回の架空テストから、集約そのものが危険だという結論は出ない。正しい設計を全体へ広げられることは、集約の大きな便益である。

集約の利点と、同じ誤りが広がる条件

同時に、共通の対応表に誤った条件が入れば、それを利用する複数の入金経路へ影響が及ぶ可能性がある。ある銀行で使う番号形式の変更が、関係のない銀行の取引まで動かすなら、共通化の境界を見直す手掛かりになる。検査では、修正対象の経路で成功することに加え、変更していない経路の取引IDと金額が動かないことも確認する。同じ日に多数の経路で結果が変わるなら、個別の顧客操作より共通処理を先に調べる理由になる。

顧客への実害が確認されていない場合、計算上の不備を大きく扱い過ぎではないかという見方もある。実害の有無は、顧客の損失や不便を評価するうえで欠かせない。他方、日次計算の検査は、損失が起きる前に誤った資金手当てへつながる条件を見つけるために役立つ。潜在的な経路を説明することと、損失が実現したと主張することは別である。どの記録で検査が通らなかったかを示す方が、危険という形容詞を重ねるより明確になる。

厳しい検査にも誤検知の費用がある。例えば、正当な訂正を重複とみなして止めれば、処理待ちが増える。その場合は、例外を黙って除くのでなく、元の入金へ結び付けて解消できる資料を求める。仕組みの評価は、検知件数が多いほどよいとも、例外がゼロならよいとも限らない。D3のような資金を残し、D4を除き、正当な更新を二重に数えないという異なる条件を、同時に満たせるかで判断したい。

入力と結果を後からたどる記録の基礎は、確認メモの版と根拠を残す方法を読むも参照できる。公開解説であり、案内先の運用機能は有料。資金保護の適法性を判定するものではない。

13

七つの架空記録で、入金の集合を手で再現する

読者がこの比較を試すには、紙や手元の表に七つの記録を書けばよい。銀行入金はD1がAを参照して100ユーロ、D2がBで60ユーロ、D3が未一致のUで20ユーロ、D4がGで20ユーロの四行とする。別の三行には、AとBはCBIE、Gは別法人と書く。D3については、顧客参照は未一致だが、別資料でCBIEの電子マネーに関する資金と確定しているという条件を添える。これが七行の出発点である。

最初に、対応表を見る前の銀行入金四件を数える。その後、対象として含める取引IDを別の紙へ書き、各IDについて採用した金額を一つだけ記す。対象になった理由も短く付ける。D3には対応表から答えが出ないため、追加条件を使ったことが見えるようにする。D4が対象外になった理由を残せば、すべての銀行入金を足した合計との違いも説明できる。元の四行は、検算が終わるまで書き換えない。

次に、自分が作った対象一覧を隠し、七行と追加条件からもう一度対象IDを選ぶ。先の答えを写すのではなく、選んだ記録と根拠を突き合わせる。正しい合計になった場合も、二つの一覧でD3とD4が入れ替わっていないかを見る。各行の採用回数を正の字などで数えれば、一つの入金を複数回使ったかも分かる。この小さな手順なら、足し算をする前の選別に誤りがあるのか、足し算そのものなのかを分けられる。

答えを見ずに、変化するはずの箇所を決める

続いて、図のテストから一つだけ選び、入力を変える前に期待する結果を書く。Aの対応行を複製するなら、入金D1自体は増えないと記す。D3へ顧客番号を補うなら、対象額は維持され、未割当という分類だけが変わると記す。行の順番を変えるなら、対象IDも合計も変わらないはずだ。結果を見てから説明を作るのでなく、変わる範囲を先に決めると、予想外の影響を見つけやすい。

実データへ応用するときは、銀行の取引IDが再利用されないか、同じ入金が複数の明細へ載っていないかも確認する。照合に使うIDが信頼できなければ、合計が正しくても検算の土台が弱い。実務資料には、銀行の明細、取引の状態、顧客への義務を示す記録、対応表を変更した理由などが要る。一般の顧客がそれらすべてを閲覧できるとは限らず、自分の入出金履歴だけで事業者全体を再計算することはできない。

この手作業の成果は、事業者への安全判定ではなく、どの説明があれば検算を一段進められるかが具体化することである。例えば、未一致の入金を落とさない処理、同じ入金を一度だけ数える根拠、訂正前後の構成差などを質問できる。個人の口座番号や本人確認書類を公開する必要はない。合成した記録と仮の参照番号のまま、例を動かして考えられる。利用中のサービスへ問い合わせる場合は、そのサービスの正式な窓口と必要な範囲の資料を使う。

14

評価を変えるのは、修正後の取引が残る証拠

次の資料で注目したいのは、仕組みを変更したという説明の具体性である。未一致の入金が対象から落ちないこと、重複する対応候補を解消すること、訂正を元の取引へ結び付けることが、実際の検査で確かめられていれば評価を進めやすい。顧客名や口座番号を開示する必要はなく、匿名化した検査範囲や失敗した事例の扱いでも、説明できる部分はある。処理の名称や担当部署を変えたという情報だけでは、この検算には答えない。

好転する条件は、修正対象の入金が正しく残り、対象外の入金も引き続き除かれることである。そのうえで、同じ入力を使った再実行が一致し、別の入金経路でも同じ規則が機能すれば、問題を局所的にふさいだだけという懸念は弱まる。金額差をゼロにした報告に加え、どの取引が増減したかを説明できれば、変更の影響も見える。検査が一度通った日だけでなく、訂正や例外が生じた状態で機能するかが焦点になる。

逆に、対象額は修正されたのに、どの入金が戻ったか説明できない場合は検算が止まる。前より多くの資金を置いたという説明があっても、誤った構成のまま計算する条件が残れば、資金需要が変わった日に同じ弱点が現れる可能性がある。別経路で対応表の未一致が増えたり、再実行で合計が変わったりする観測も、追加調査の理由になる。これらは将来を見るための条件であり、現にそうした状態が続いているという主張ではない。

好転・悪化を、検算できる条件で読む

混合した結果もあり得る。取引の脱落は減ったが例外処理が積み上がる場合、資金の計算と顧客対応の改善度は同じとは限らない。集計は正しくても、追加の確認作業に時間がかかるなら、処理能力や人員配置を別に見る必要がある。一方、未処理件数が増えても、それまで見えていなかった記録を拾ったためなら、直ちに悪化とはいえない。件数の増減を、対象の変更と解消能力へ分けて読む必要がある。

法的な手続きの進展と、計算の実務を示す資料も、答える問いが異なる。処分がどの段階にあるかは、当局や裁判所の正式な資料で追う。現在の資金保護の運用を知るには、その後の事業者の説明や監督上の資料が別に必要になる。制裁金の額を顧客の損失額へ置き換えたり、過去の違反が公表されたことだけで現在の残高不足を推定したりすると、どちらの問いにも正確に答えられない。

SG Groupの評価は、残高の数字へ至るまでに、入金が残る条件を検算できるかにある。D3を落とさず、D1を二度数えず、D4で穴を埋めないという架空例は、三つの異なる失敗を見える形にする。読者は、報告された合計と同じ数字を作るだけでなく、元の取引から同じ構成を再現できるかを確かめられる。実際の運用に関する判断を前へ進めるのも、安心や危険という評価語より、この途中の計算を説明する証拠である。