- 銀行は 元帳 のように資金移動を追跡することには強いが、口座閉鎖・詐欺対応・カード再発行・差し押さえのように長い文脈を要する事案では、顧客にとって「記憶のない組織」のように見えることがある
- 問題の中心には、コアバンキングシステム、元帳、チケットシステム、部門ごとのツールが別々に動く 分断された記録体系 がある
- カスタマーサポートはコストを下げるため Tier One・Two・Three に分かれており、権限と引き継がれる文脈が制限されるほど、顧客は同じ問題を何度も説明することになる
- 公式なサポート階層を迂回する エスカレーション 経路もあり、記者・規制当局・上位部門に持ち込まれた問題は、はるかに高コストな専門組織が処理できる
- Suspicious Activity Report (SAR) のような非公開義務は、口座閉鎖の理由を説明できなくし、悪い顧客体験の一部は技術の未熟さだけでなく規制上の選択の結果でもある
銀行が「記憶できない」理由
- 銀行は資金移動を記録する 元帳 には強いが、顧客との会話、過去の約束、数か月または数年にわたる事案の文脈といった別種の真実には弱い
- 口座閉鎖、Zelle やクレジットカード詐欺、デビットカード再発行、住宅ローン差し押さえのような異なる問題でも、顧客体験は似た形で繰り返される
- 毎回最初から説明しなければならない
- 前の担当者がした約束が次の担当者に伝わらない
- 銀行内部で責任の所在が曖昧になる
- こうした事例は銀行全体の活動から見れば例外的だが毎日起きており、一部の顧客には非常に大きな被害につながりうる
コアバンキングと記録システムの限界
- 銀行の中核業務は通常 core と呼ばれるシステムで処理される
- 大手銀行は複雑な独自の下位システムを持つことがある
- 多くの銀行は Jack Henry、Fiserv などのコアプロセッサのシステムをライセンスしている
- core は銀行業務の大部分を担うが、銀行内部の多数のシステムや元帳と接続されているため、現実を期待するほど正確に表現できない
- 銀行システムは、長年のソフトウェア開発、規制変更、競争圧力が積み重なった堆積層に近い
- 責任が組織、コンピュータシステム、銀行内部のグループの間を移るたびに、一部のケースが壊れる
- 銀行運営上の問題の大きな割合は システム境界 で発生する
- セキュリティ脆弱性も、システム A と B が同じ現実を一時的に異なって判断するときに生じうる
チケットシステムも完全な解決策ではない
- チケットシステムは、ケース番号付きの問題が Group A から Group B に渡ったという単純な不変条件を強制する
- Group B が 10,342 件を処理中であることを確認できる
- Group B が 1か月間対応していない 76 件を確認できる
- 特定の従業員の処理実績が同僚と異なることを確認できる
- しかしチケットシステムは core ではなく、実際の顧客口座や決済に直接責任を持つシステムでもない
- チケットシステム自体も別の下位システムと統合されなければならず、そのインターフェースで新たな問題が生じる
- 銀行システムには、設計された部分と偶然積み上がった部分が混在している
M&A が残す並行システム
- 銀行業界は数十年にわたり 統合 を経験してきたが、合併された銀行はシステムをすぐにひとつへ吸収できない
- 合併後は二つの銀行のシステムが何年も並行運用され、統合計画はたいてい一方のシステムが「勝者」となり、もう一方が「敗者」となる方向で進む
- 事業上の理由から敗者側システムの一部は無期限に残り、古いシステムと過去の買収先の残存構造が勝者側システムに接ぎ木される
- First Republic を買収した Chase の事例では、双方のシステムは同じ人物が両方に口座を持っていることは認識しているが、重要情報はまだ共有できていない
- Chase は First Republic が使っていなかった住宅ローン移行スケジュールを案内する
- First Republic が実際に提供した Line of Credit を把握していない
- First Republic core がサービスする口座残高を Chase 支店で確認するには追加の統合作業が必要である
社内向け画面も現実とずれることがある
- 銀行は、従業員が顧客口座を見て対応できるように、core や元帳に接続された複数の社内システムを作る
- この従業員向け画面も口座の実際の状態と異なることがある
- 例えば一部の画面は 保留中取引(pending) を表示しないことがある
- 保留中取引は顧客の観点では確定取引とほぼ同じ結果をもたらしうる
- こうした欠落は、誰かが意図的に「pending 取引を除外しよう」と決めたからではなく、古い要件文書やコードに残った単純なミスが長期間存続した結果かもしれない
- 銀行ソフトウェアの問題をオペレーション部門がエンジニアリングや調達組織に伝え、修正させる構造を持つ会社は、思われているより少ない
階層化されたカスタマーサポート構造
- 銀行はコストを下げるため、カスタマーサポート組織を職務と権限ごとに強く分けている
- 一般的な金融機関のリテールバンキング支援は Tier One、Tier Two、Tier Three に分かれる
- Tier One は最も単純な問題を処理するか、Tier Two に渡す役割を担う
- 制限された読み取り専用インターフェースと、いくつかの事前定義されたボタンを持つ
- スクリプトとフローチャートに従って、顧客の Tier Two へのアクセスをゲートする
- Tier Two はより多くの経験と限定的な補償権限を持つ
- 任意の理由で少額を顧客口座に入金し、運用損失として処理できる
- 例として、およそ 200 ドル以下の補償には管理ラインや専門家を通さずに済む上限があることがある
- Tier Three はカスタマーサポートまたはオペレーション組織に属し、単純なスクリプト実行よりも、複雑な事案の再構成と問題解決に近い仕事を行う
- 複数システムから帳簿に残らない手続き履歴を集める
- 意思決定者ではないが、別の専門家が判断できるよう事案全体を整理する
顧客が同じことを繰り返し言わされる構造
- Tier One から Tier Two に渡る際、引き継がれる文脈は非常に短いことがある
- うまく運用されているシステムでも、引き継がれるのはツイート 1 本分程度の要約にすぎないことがある
- 多くの金融機関はそのレベルにも達していない
- 顧客は Tier Two や Tier Three に到達しても、同じ問題を最初から説明し直さなければならないことがある
- 部門間の移管でも同様の問題が繰り返される
- 例えば、銀行が顧客に小切手を送るはずだったが郵便で届かなかった場合、Tier Two には「小切手再発行」ボタンがないかもしれない
- Tier Two はオペレーション部門にチケットを上げ、「誰かが電話する」と伝えるしかない
- 実際に電話が行われたか確認するシステムがないこともある
- 顧客は嘘をつかれたと感じるが、Tier Two 担当者はただスクリプトを読んだだけで、オペレーション部門は常に燃えている現場を処理しており、上級経営陣はこの問題を切り分けて見るための指標を持っていないかもしれない
支店スタッフも万能の解決者ではない
- 伝統的な銀行の顧客は支店スタッフや支店長が問題を解決できると期待するが、銀行支店の熟練度は低下している
- 多くの支店スタッフは比較的単純な問題しか解決できず、複雑な問題では顧客と同じように電話サポートのツリーをたどらなければならない
- 一部の銀行では支店画面と Tier Two 担当者の間で文脈を共有できるが、場合によっては従業員が自分が銀行員であることすら銀行に証明できないことがある
- 米国の金融機関の技術的成熟度は、機関ごとの差が非常に大きい
公式階層を迂回するエスカレーション
- ほぼすべての金融機関には、一般的なサポート階層を大部分または完全に飛ばして意思決定者に届く エスカレーション 経路がある
- 記者が不当な差し押さえ寸前の未亡人の事例について銀行にコメントを求めたり、規制当局が個人に代わって介入したりすると、その問題は問題解決専任チームに送られる可能性が高い
- 一般顧客でも、VP of Retail Banking、Office of the President、Investor Relations などに紙の手紙を送れば、同じように銀行を動かせる
- これらのチームは、複雑な事案で紙のメモを維持し、数日にわたる記憶と裁量をもって働ける専門家である
- このような処理方式は非常に高コストであり、問題解決チームの 1 件あたりコストは階層型サポートシステムより 100 倍以上高いこともある
なぜ全員に専門家サービスを提供しないのか
- どんな問題でも処理できる高裁量の専門家サポートは非常に高価で、時間がたつほどさらに高くなる
- 顧客が銀行への電話は午前 2 時でもつながり、しかも無料であることを望むなら、銀行は階層型サポートシステムを選ぶことになる
- 社会も階層型サポートシステムを望んでいる
- 高校生でも当座預金口座を開き、デビットカードで Amazon から購入できる
- 労働者階級の地域にも銀行支店を運営できる
- 洗練された銀行利用者にとっては、自分の問題が Tier Two で解決しそうか、それとも 6 桁年収の専門家を必要とする問題かを見極める能力が有用である
- 迂回経路は偶然ではなく意図的に設計されており、専門職・管理職層らしく見える振る舞いや、金融業界の目印を求めることで乱用を減らしている
疑わしい活動報告と説明できない口座閉鎖
- 銀行が理由も告げずに口座を閉鎖し、誰も説明しない場合、銀行は法令を守っているのかもしれない
- 銀行は顧客について複数の Suspicious Activity Report (SAR) が提出された後、「独立した」「商業上の判断」として取引関係を終了できる
- SAR は無害な理由でも提出されうるもので、必ずしも不正を意味しない
- SAR は規制上、秘密である
- コンプライアンス組織は、SAR が別個の下位システム内に留まるようにし、作成して FinCEN に送る担当者だけが見られるようにしていることが多い
- SAR 下位システムが口座保有情報を他システムと異なって見ている場合、誤って提出された SAR の調査でさえ、顧客に調査の存在を知らせてしまう問題と衝突しうる
何が変わりうるのか
- 銀行の「オブジェクト永続性の欠如」は一夜にして生まれたものではなく、一夜にして直るものでもない
- 解決のかなりの部分は 技術的改善 にある
- かつてはソフトウェアに強い金融機関はほとんどなかった
- 今では数百億ドルを費やした末に、ごく少数の金融機関がその能力を獲得した
- 階層型サポートモデルは顧客にとって苛立たしいことがあるが、金融サービスのコストを下げ、クレジットカードやディスカウント証券会社のような製品革新を可能にした技術でもある
- 改善はいくつかの経路で進みうる
- 続く銀行統合
- 正しい事実を自動で記録し対応する外部技術ベンダーの活用
- オペレーションがより高い地位の分野となり、銀行内部の構造を変えていく過程
- Cash App と Lincoln Savings Bank のように、技術的な顧客体験を前面に出す企業と銀行の提携
- 12 CFR § 21.11(k)(1) のような規則には社会が望む目的があるが、その規則が存在する限り、理由を聞けない口座閉鎖を経験する米国人は今後も生まれ続け、その多くは何も悪いことをしていない可能性がある
1件のコメント
Hacker News のコメント
Patio11 は、制度の世界がどのように回っているのか、そしてそのバイアスを理解するうえで、私が知る限り最高の資料です
制度は、ある行動には報酬を与え、別の行動には与えないように繰り返し設計されており、常に報酬を受ける行動の一つが 専門職・管理職階層の優先アクセス権 です
この記事は銀行内部の仕組みを通じてそれを示しています。さらに胸に刺さる記事は https://www.bitsaboutmoney.com/archive/the-waste-stream-of-c... で、貧しい人を守るというルールが、実際には専門職・管理職のスキルにアクセスできる人にしか役立たない仕組みを示しています
彼の視点を人々に要約して説明する方法があればいいのですが、こうしたことが起こるシステムはいずれも非常に複雑で、その複雑さ自体が、優先的にアクセスするために専門職・管理職のスキルが必要になる理由になっています
ただし、@patio11 が今年示したいくつかの解釈は、そのまま伝えるのが難しいものでした。銀行内部の複数の階層ではもっともらしく聞こえるものの、実際に機能している理由ではない場合があり、おそらく彼が接している組織の階層やサイロ、あるいは G-SIFI のような他種の銀行よりも特定タイプの銀行に多く接している影響だと思われます: https://www.fsb.org/work-of-the-fsb/market-and-institutional...
それでも、改善に関心のある業界幹部なら全員読む価値があります。@patio11 がいつもとは違うレンズで見る「認識が現実である」部分が明らかになり、原因の帰属が違っていても、その認識を変えるために何を直すべきかを引き出せます
こういうコメントに燃やすためにカルマを貯めておきました
元記事の画像は Atlantic、Wired、New Yorker などの人間が描いた抽象画のようにかなり複雑で、ほぼ唯一の手がかりは壊れた文字でした。コメント先の記事は 2023 年 8 月の記事なので、数か月の品質差だけでもかなりの進歩を示しているように思えます。おそらく DALL-E 3 かもしれません
あるいは同じ出所の画像で、記事ごとに違う美感を選んだだけかもしれませんが、いずれにせよかなり良いです
現実的な解決策は、Patrick を手本にして、専門職の人々に、自分より運が悪い、あるいは教育・知識が不足している人のために一定の時間を代弁するよう求めることかもしれません
さまざまな系統の社会科学者がこうしたテーマについてよく書いており、銀行分野のことはよく知りませんが、政治、技術、社会、アイデンティティといった要素の交差点を、読みやすくかつ詳しく扱った本は多くあります
HN 読者が Patio11 の文章に惹かれる理由の一つは、社会科学者があまり得意ではないやり方で、技術的な厳密さをもって書いているからだと思います。多くの社会科学はデジタル世界の「中身」の周辺を少しずつかじっているように感じますが、扱うべきものは多く、分野も大きくありません。そのため原典を読むと良い内容はあっても、自分の働く分野を説明するときに間違っているように見える部分が出てきて、もどかしくなることがあります。一方 Patrick は細部も当て、一般的な社会学も当てています
James C. Scott は CIA の資産でもありました。矛盾した人物とも言えますし、パターンとも言えます。優れた人類学者には、意外と議論の多い人物が多いものです
記事で参照されている Seeing Like a State は本当に素晴らしい本です: https://www.amazon.com/Seeing-like-State-Certain-Condition/d...
強くおすすめしますが、まず要約に目を通して、楽しく読めそうか、役に立ちそうかを確認するとよいです: https://en.wikipedia.org/wiki/Seeing_Like_a_State
ここで読みたいものを見つけると、たいてい最初に図書館へ行きます
この点をもっとよく伝えたい：組織はチームで構成されている
あまりにも当たり前に聞こえるが、どんな変更依頼も最終的には1つまたは複数のチームに行き着くという意味だ。
外から見ると企業は事実上無限のリソースを持っているように見えるが、内部から見ると特定のチームが持つリソースは非常に限られている。そのチームは人員削減を受けたばかりだったり、リーダーを失っていたり、組織再編を経験していたりするかもしれない。
「そのリテール利用者は、銀行口座、金融全般、そしてしばしば人生のさまざまな面で極度に未熟だ」という文には笑った。
大企業と多く仕事をしているが、私がサポートしているソフトウェアで問題が起き続ける理由は、運用コストを下げ続けろという指示があるからだ。よく訓練され、ソフトウェアをよく理解し、ほぼ100%に近い状態を維持していたチームがあったのに、ある日突然全員いなくなり、専門ソフトウェアについて何も知らない海外アウトソーシングチームが入ってくる。コンピュータの電源を入れられたら驚くほどだ。
ソフトウェアの可用性は大きく落ち、納品に直接影響し、会社によってはどれだけのコストがかかっているのか分からない。サプライヤー側のサポートは巨大で高コストな混乱状態になり、今では「用を足したら水を流し、ズボンを上げ直してください」レベルの手順書を書かなければならない。
組織のリソースをチームに分けることは本質的に messy で非効率なので、解決が難しい。チームを作る際には社内政治、中間管理職のプライド、個人の好みを考慮しなければならず、その結果は組織全体にとって最善のものからは遠いことが多い。
「Opsは壊れていないソフトウェアを使えず、それに文句を言うのは重力に文句を言うようなものだと学んだ」という部分は、銀行に限らずどこでも見られる。
よくある作業フローが何十もの習慣的な回避策でひどく壊れているのに、開発者が問題を知りさえすれば1日で直せることが多い。チーム間の依存関係があるエンジニアリングチーム同士でも見かける。
人々が自分の作業フローの慢性的な痛みをただ我慢しないように訓練するのは、本当に難しい。
「間違った答えが出ている」とか「1日にXX人時が無駄になっている」といったことは検討対象ではない。何も変わってはいけない。
銀行のIT運用では、すべての部署が深い責任回避モードに入っている。「問題を見つけて特定しよう」ではなく、「自分の責任ではない」モードだ。私たちのアプリケーション性能がほぼゼロまで落ち、ディスク操作が分あたり数件レベルまで下がったとき、顧客には何時間もインフラの問題だと伝えた。
インフラチームを呼んで原因を探らせたが、どこもまったく役に立たず、第一声は「すべて正常、私たちの問題ではない」、第二声は「私たちは何も変更していない」だった。
2日にわたる10時間の通話の末、NASチームに、NAS側でアンチウイルスを有効にし、CPUが跳ね上がって機器が溶け落ちそうになっていたことを認めさせた。それ以前の人たちは指標も見ずに「自分の問題ではない、すべて正常」と答えていた。
他の開発者に聞くと「広告チームが必要としている手順だ」と言い、広告チームに別途聞きに行くと「開発者たちがこう必要としているので仕方ない」と言われた。
分かってみれば、双方とももっと良い方法を望んでおり、3種類のページ・広告位置テンプレートでかなり簡単に解決できることだったが、互いに話していなかっただけだった。
その人は体調の良い日には何でもできたが、悪い日にはただオフィスから人を追い出したがっていた。実力が証明された人だったので、チームは彼の言葉を福音のように受け止めていた。
毎週1〜2時間ずつ「不可能」なことを引っ張り出して直していくと、チームはとても喜び、私に魔法使い級の能力があると思うようになった。
そもそもそうしたフローが存在したのかを識別できるほどにもなっていないことがよくある。
「たまに保留音を聞くことがあっても、クレジットカードとディスカウント証券会社がある世界を好むべきだ」という主張には問題がある。
私たちは30年前から、待たせるシステムよりコールバックシステムのほうが優れていることを知っていた。こんな基本的なこともできないなら、銀行がいつかソフトウェア能力を身につけるとしても、その頃には私はとっくに死んでいると思う。
電話詐欺が蔓延しているからだ。
他の国でもクレジットカードやディスカウント証券会社を使ったことがあるが、米国の顧客対応は際立って悪いと思う。
すでにつながっている状態のほうが、さまざまな理由で失敗するかもしれない将来の接続の約束よりも安全に感じられる。
記事には「銀行は一種類の真実、つまり台帳を追跡することに極めて長けている」とあるが、場合によっては驚くことに、それすら事実ではない。
少なくとも顧客の立場からは、あまりに直感に反し、文書化されていない方法で台帳を運用していて、筋が通らないこともある。よく見ても銀行に有利なやり方だ。
銀行は顧客の大金に気を配るべき存在なのに、これは問題ではないのか？ 当然問題だ。
よくある低残高の当座預金口座を超えると、激しい競争があるという話も自己正当化に見える。たとえばFATCAは、米国居住者が欧州の銀行口座を運用する際の競争を事実上なくしてしまったし、米国で金融資産を担保にお金を借りようとしてみれば、どれほど競争があるか分かる。
それでも実際には、世界最大級の主流銀行の1つで年に1〜3回、目を丸くしながら時間をかけて「この程度なら大丈夫だ」と自分に言い聞かせ、その馬鹿げた内容をIRSにどう提示するか整理し、納税申告のためにメモを残し、忘れた後に再調査しなくて済むよう記録してから、ようやく日常に戻る。銀行にとっては、その台帳はうまく帳尻が合っているのだろう。
開発者として通常の開発業務の傍らでレベル3サポートのような仕事をしているが、技術的負債や古いシステムが多い会社なので、奇妙な例外ケースやエスカレーションを処理するのが密かな楽しみになっている
顧客が経験していることを見ると腹が立つこともある。カスタマーサポート担当者は、標準から外れたケースに遭遇すると明らかに混乱している
以前、コアバンキングシステムを販売する会社で働いていたが、本当にひどかった
2023年にもまだああいうシステムが動いているとは想像もしていなかった。恐怖事例だけで本が1冊書ける
驚くべきなのは、顧客を喜ばせたり革新したりすることに大きく失敗していても、多くの銀行はそれなりにうまく回っているという点。銀行は文字どおり「お金を刷る免許」だ
大手銀行間の大規模な送金問題を経験して、この状況を直接目にした
支店の職員が電話の相手に自分の身元を証明できない様子を見て、面白くもあり不安でもあった。支店のコンピュータの前にいることを証明するために、あるワンタイムパスワードを共有しなければならなかったのだが、そのパスワードを生成または伝達するマイクロサービスが落ちていた
有能な詐欺師なら、あまりにも簡単にソーシャルエンジニアリングで悪用できる
多くの銀行システムがひどい理由は、銀行にとってそれがあまり重要ではなく、むしろ利益になることさえあるからだと思う
銀行を変えるのはかなり難しく、銀行は実際に乗り換えを難しくする障壁を設けている。ローンを移すと大きな「再契約手数料」がかかることがあり、ローン保証はほぼ移転不可能な場合があり、口座情報は多くの場所に散らばっていて、うまくいかないと支払いが漏れる可能性がある
良い例として、フィンランドで通信会社が電話番号を移せるようにしなければならないのと同じように、銀行口座番号も別の銀行へ移せるようにしようという提案があったとき、銀行のロビイストたちは技術的に不可能だと言った。当然ながら、まったくのナンセンスだ。そして今の時代でも、銀行振込の決済に何日も待たなければならない
Monzoのような新しい銀行を使ってみると、ほとんどの銀行がただひどいだけだということが本当によく分かる
無からお金を作り出す免許があれば、ロビー活動以外の分野では本当に無能でも莫大な利益を上げられる
しかし口座にはIBAN番号もあり、そこには国と銀行・機関の識別子が含まれている。顧客が銀行を移ると、国際金融法が変わらない限り、その番号は変わらざるを得ない
私の知る限り、IBANはほぼあらゆる場所で広く使われている。だから問題を本当に解決するわけではなく、複雑さの層を1つ追加するだけになる
電話番号はすべての通信会社全体で一意でなければならないと義務付けられているので、移転が可能だ。銀行口座番号は各銀行内の番号であり、さまざまな任意の要因に基づいて作られている
移ろうとしている銀行に、既存の銀行での自分の口座番号と同じ番号の口座がすでにあった場合、どう動作すべきなのか？
私があなたに100ドルを貸し、あなたがその100ドルをさらに別の人に貸したなら、貨幣的な意味では「100ドルを創出」したことになる。しかし会計の観点では、無から出てきたのではなく、ある人から別の人へ債務が移動しただけだ
新しい銀行が企業に新口座を通知することもでき、その企業は自社システムの口座番号を変更する
こうしたサービスが存在し広く使われているのは良いことだが、銀行を根本的にましなものにはしなかった
結論として、個人の当座預金口座は銀行にとって概してロスリーダーに近い。だからコスト削減、たとえば階層化されたサポートシステムが非常に重要になる。実際のお金は他の商品、つまり融資や住宅ローン、特に法人顧客から稼がれる