学習・操作
コアバンキング、クラウド、アウトソーシング、技術規制
コア銀行システムの仕事 アウトソーシングとクラウドルールがどう銀行に適用されるか DORA どのように技術が規制報告を支援するかです
キーポイント
- 01銀行のコアシステムは顧客,口座,残高,利息を記録する銀行のレジストリであり,他のすべてのシステムがそれに依存している。
- 02銀行はクラウドを含めてアウトソーシングすることができるが、完全な責任を負うことはできない。
- 03In the EU, DORA has applied since 17 January 2025.ICTリスクフレームワーク,メジャーインシデント報告,レジリエンステストおよびすべてのICT第三者契約の登録が必要である。
- 04規制報告は財務的な問題と同様に技術的な問題である。 AML 正確に 時間通りに報告する
銀行は大帳に記録された約束の集合体である。大帳が間違っていたり、利用できなくなったり、または破綻した場合、銀行は負債を知ることも、顧客に支払いをすることも、監督者に報告することもできない。このため、規制当局は今や技術アーキテクチャ、アウトソーシングおよびサイバーレジリエンスを資本計画と同じように厳密に検討している。
コア銀行システムの役割は
コア銀行システムは記録の大簿であり 顧客と口座データを保持し 全ての取引を記載し 利息と手数料を計算し 他のすべてが依存するバランスを生成します
典型的な機能は以下のものを含む
| 機能 | 内容 |
|---|---|
| 顧客管理 | 顧客記録、口座開設、製品条件、口座状態 |
| 帳簿と入金 | クレジット・デビットのリアルタイムまたはバッチ入力、総帳フィード |
| 入金 | 流動・貯蓄・定期口座、利子累積及び資本化 |
| 借りる | 融資発行インタフェース,スケジュール,返済,遅延,プロビジョニングフィード |
| 支払いインタフェース | 支払いハブ、カードプロセッサおよび対応口座への接続 |
| 製品設定 | コード変更なしの料金・手数料・制限・ルール |
| データと報告 | 財務,リスク,規制報告および AML 監視 |
コアの周りには,デジタルチャネル,支払いハブ,カード管理,顧客オンボードと身分確認,制裁スクリーニング,トランザクションモニタリング,財務,金融および規制報告エンジンなどの他のシステムがある。
アーキテクチャ選択
New banks usually choose between three models.
- ライセンスソフトウェア、銀行またはプロバイダによってホストされる。 銀行はコンフィギュレーションとデータをコントロールするが,統合の負担を負う。
- クラウドプラットフォーム上のサービスとしてのソフトウェア。 開発は早いが,ベンダーのロードマップやレジリエンスに依存しており,外注方式である。
- 他の免許を持つ機関からのサービスとしての銀行業務。 最も速いルートだが、新しい銀行が十分な実質を持っているかどうかの疑問が生じるかもしれない。
監督者はモデルを指示するのではなく、銀行が選択したモデルを理解しコントロールしているかどうかを評価する。
アウトソーシングルール
アウトソーシングとは,銀行が自ら行うべきプロセス,サービスまたは活動を,サービスプロバイダに委託することである。In the EU, the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) entered into force on 30 September 2019.They replaced earlier guidance, including the EBA’s separate recommendation on outsourcing to cloud service providers.
責任はアウトソーシングできないという中核原則,すべてのアウトソーシングされた機能に対して経営団体が責任を負うこと,組織は「いつも十分な実質を保持し,「空の殻」や「郵便受けの存在」になることはない」。
重要機能
このガイドラインは,外注機能が重要かつ危機的であり,その失敗がコンプライアンス,財務成績または継続性に重大な影響を及ぼす場合には,より厳しい要求を適用する。
- 契約前にプロバイダのリスクアセスメントとデューイ・ディリジェンスを行う。
- 銀行と主管機関に対するアクセス,情報および監査の契約権を含む。
- 外注制御,通知,拒否権,終了権を含む
- データのセキュリティ,位置,機密性要求を設定する。
- 退出戦略を文書化し,テストした。
- 計画中の重要なアウトソーシングについて事前に当局に通知する。
すべての取り決めは銀行が保持するアウトソーシング登録簿に記載されなければならない。
EU以外
同様のルールは他にも適用される。In the United Kingdom, PRA Supervisory Statement SS2/21 on outsourcing and third party risk management, published in March 2021 and effective from 31 March 2022, covers materiality, data security, cloud and exit planning.The PRA describes it as intended to facilitate “greater resilience and adoption of the cloud and other new technologies”.
In Singapore, the MAS Technology Risk Management Guidelines, published on 18 January 2021, set principles for technology risk governance, IT and cyber resilience, and are supplemented by a binding notice and incident reporting instructions.
DORA:欧州連合のデジタル運用耐性
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025.ICTリスクマネジメント,インシデント報告,テストおよび第三者リスクを銀行を含むほとんどのEU金融機関に対して一つの規制にまとめた。
| DORAエリア | 銀行に対する核心要求 |
|---|---|
| ICTリスクマネジメント | 管理機関が承認し監督する文書化された枠組みで,同定,保護,検出,応答および回復を含む。 |
| 事故報告 | ICT関連の重大事故は,次の規定に基づき主管機関に報告しなければならない。 第19条統一分類とテンプレートを使って |
| 耐久性テスト | すべての実体に対するテストプログラム;for entities identified by authorities, advanced threat-led penetration testing at least every three years on live production systems under Article 26 |
| ICT第三者リスク | ICT第三者リスクに関する戦略,契約上の最低限度,およびICTサービス契約に関するすべての情報の登録について述べた。 第28条 |
| 重要プロバイダの監視 | 欧州監督機関は第31条に基づき、重要なICT第三者サービスプロバイダを指定し直接監督する。 |
第28条では,ICTサービスを利用する金融機関は「いつでもすべての義務の遵守と履行に対して完全な責任を負う」ことを規定している。 DORA また,クリティカルかつ重要な機能を支援するサービスを区別し,新しい仕組みについて年次報告を行い,クリティカルかつ重要な機能の契約計画については適時に当局に通知することが求められている。
DORAはEBAのアウトソーシングガイドラインと並行して適用される。実際には,銀行は両者を満足させる一つのインベントリを維持する。
サイバーセキュリティ
サイバーリスクは今や慎重監督の一部となっており,監督者は銀行が情報資産を知り,その重要性に応じて保護し,攻撃を迅速に検出し,定義された許容範囲内でクリティカルサービスを回復することを期待している。
キーコントロールは通常以下を含む:
- マルチファクタ認証と特権アクセス制御を備えた強力なアイデンティティとアクセス管理。
- ベンダーリリースを含むセキュリティソフトウェア開発と変更管理。
- データの転送と停止の暗号化,銀行が管理する鍵管理。
- 継続的な監視とセキュリティ運用能力,内部またはアウトソーシング。
- 脆弱性管理と定期的な侵入テスト。
- プロダクション環境から隔離され,復元のためにテストされたバックアップ。
- 規制通知と顧客コミュニケーションを含む事故対応計画。
支払い受け手の確認,行動分析および強力な顧客認証は,支払いが即時で不可逆になるように顧客を保護する。
規制報告
銀行は監督者や中央銀行に 大量のデータを報告する。 民法第430条 CRR 金融機関はレバレッジ比率,大規模リスク,流動性要求,資産負担,ESGリスクなどの自己資本要件を報告し,一部の金融機関は財務情報も報告する。
コアシステムからレギュレータへの連鎖は通常次のように進む。
- コアシステムと他の運用システムにおけるソースデータ。
- データウェアハウスまたはレポート層で,総帳簿との調整を行う。
- データを監督テンプレートと検証ルールにマッピングする規制報告エンジン。
- 財務とリスクの検討と承認,文書化されたコントロール。
- 規制当局のポータルまたはフォーマットを通じて提出する。
新しい銀行は,発売前に製品データを報告テンプレートにマッピングする作業を過小評価することが多い。
免許申請書に監督者が求めるもの
- 明確なターゲットアーキテクチャそれぞれのシステムと その所有者、プロバイダ、そしてその場所です
- 重要な機能マップどの機能が誰にアウトソーシングされているかを示しています
- 脱出計画 時間とコストに関して現実的なものを提供する必要があります
- データの位置とアクセス監督・解決機関を含めて
- テストレジリエンスまた,事業計画のサービスプロミスと一致する回復時間を実現した。
- 準備状態証明エンドツーエンドテスト,マイグレーションリハーサルおよび運用承認などを行った。
ザ・ ECBフィンテック銀行のライセンス取得に関するガイドライン 消費者を傷つけることなく、規制の介入を必要としない秩序的で有効な方法で事業を停止するための撤退計画を考慮することを求める。そのような計画が信頼できるかどうかは、技術選択によって決まります。データは検索可能でなければなりません。口座は移転可能であり、支払いはきれいに停止できます。
次に,コアシステムが接続する支払いレールについて説明した。 SEPA即時支払いとリアルタイムの総決済です
Sources(6)
- EBA: Guidelines on outsourcing arrangements (EBA/GL/2019/02) · checked 2026-10-07
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) · checked 2026-10-07
- Bank of England PRA: SS2/21 Outsourcing and third party risk management · checked 2026-10-07
- Monetary Authority of Singapore: Technology Risk Management Guidelines · checked 2026-10-07
- Regulation (EU) No 575/2013 (Capital Requirements Regulation), consolidated text, Article 430 · checked 2026-10-07
- ECB Banking Supervision: Guide to assessments of fintech credit institution licence applications (March 2018) · checked 2026-10-07
情報のみ、法律・税金・投資アドバイスではありません。 規制通知.