MAS準拠のソフトウェア開発:シンガポールのフィンテック企業がエンジニアリングパートナーに求めるべきこと

シンガポールにおけるMAS準拠のソフトウェア開発には、文書化されたセキュリティ管理、監査対応可能な納品プロセス、MASテクノロジーリスクマネジメント(TRM)ガイドラインに沿ったリスク管理フレームワーク、そして要求に応じて規制当局の審査のための証拠を提出できる能力を備えたエンジニアリングパートナーが必要です。MASライセンスの下で運営されるフィンテック企業は、本番システムのために技術ベンダーに委託する前に、これらの要件を満たしていることを確認しなければなりません。

MASコンプライアンスがソフトウェア開発パートナーに求めるものとは?

シンガポール金融管理局(MAS)のテクノロジーリスクマネジメントガイドラインは、金融機関が技術リスクをどのように管理すべきかについて明確な期待を設定しています。これらのガイドラインは、社内ITチームだけでなく、MAS規制対象事業体に代わってシステムを構築・運用する第三者ベンダーや開発パートナーにも適用されます。

シンガポールのフィンテック企業にとって、これはソフトウェア開発パートナーの選定が単なる技術的な決定ではなく、コンプライアンス上の決定であることを意味します。誤ったパートナーは規制上のリスクを生み出します。正しいパートナーはそれを軽減します。

エンジニアリングパートナー選定に影響を与える主要なMAS TRM要件

2021年に公開され、その後の通達で更新されたMAS TRMガイドラインは、ソフトウェア開発パートナーシップに直接関連する3つの領域にわたる要件を設定しています。

第三者リスク管理。 MAS規制対象事業体は、セキュリティ管理、データ取り扱い慣行、事業継続体制の評価を含む、技術ベンダーに対するデューデリジェンスを実施しなければなりません。このデューデリジェンスは文書化され、レビュー可能でなければなりません。
システム開発ライフサイクル管理。 規制対象システム向けに開発されたソフトウェアは、コードレビュー、脆弱性テスト、変更管理の要件を含む、安全な開発ライフサイクルに従わなければなりません。パートナーはこれらの慣行の証拠を提供しなければなりません。
インシデント管理と通知。 本番システムを運用または支援するパートナーは、MASの報告要件に沿った、文書化されたインシデント対応手順と通知タイムラインを持たなければなりません。

これら3つの領域にわたる文書を提供できない開発パートナーは、その技術的能力にかかわらず、MAS規制対象のフィンテックプロジェクトには適していません。

シンガポールにおける規制対象ソフトウェア開発の実際の姿

規制対象のソフトウェア開発は、異なる方法論ではありません。それは、規制当局が一貫して適用されていることを検証するために必要とする文書、監査証跡、ガバナンス体制を備えた標準的なエンジニアリング実践です。

実際には、MAS準拠の開発パートナーは以下を提供すべきです。

MAS TRM要件にマッピングされたソフトウェア開発ライフサイクル(SDLC)ポリシー
レビュー決定の記録を伴う文書化されたコードレビュープロセス
資格を持つテスターによって作成された、侵入テストと脆弱性評価の結果
すべての本番デプロイをカバーする変更管理ログ
本番データとテストデータがどのように扱われるかをカバーするデータ分類ポリシー
テスト済みの回復時間目標を伴う事業継続・災害復旧計画

これらはそれぞれ、規制当局の要求に応じて作成されるのではなく、契約前にレビューのために入手可能であるべきです。

シンガポールのフィンテックエンジニアリングが標準的なソフトウェア開発とどう異なるか

シンガポールのフィンテックエンジニアリングは、標準的なソフトウェア開発にはない制約の下で運営されています。主な違いは、チームがどう構成されるか、コードがどうレビューされるか、データがどう扱われるか、システムがどう監視されるかに影響します。

エンジニアリングチームにとって最も重要な違い:

データレジデンシー。 MASガイドラインおよび関連規制は、特定のカテゴリの金融データや個人データがどこに保存・処理できるかを制限しています。エンジニアリングチームは、後付けではなく、データレジデンシー管理を組み込んだシステムを設計しなければなりません。
アクセス制御基準。 本番システムは最小権限アクセスを実装しなければならず、すべての特権アクセスは記録されレビュー可能でなければなりません。これはパートナーのエンジニアにも社内スタッフと同様に適用されます。
監査証跡要件。 金融システムは、すべての取引とシステムイベントについて、完全で改ざん検知可能な監査証跡を維持しなければなりません。パートナーはこの能力を前提とするのではなく、構築しテストしなければなりません。
暗号化基準。 MASガイドラインは、転送中および保存中のデータに対する最低限の暗号化基準を規定しています。パートナーはシステム設計においてこれらの基準への準拠を実証しなければなりません。

契約前にシンガポールのフィンテックエンジニアリングパートナーに尋ねるべきこと

MAS規制対象業務のための開発パートナーに対するデューデリジェンスは、契約締結前に以下の質問への回答を得るべきです。

あなたのSDLCポリシー文書を提供し、それがMAS TRMガイドラインにどうマッピングされているか示すことができますか?
侵入テストをどのように扱っていますか、また比較可能な契約からのサンプルレポートを共有できますか?
クライアントシステムで作業するエンジニアの本番アクセスを管理するプロセスは何ですか?
クライアントシステムに影響するセキュリティインシデントをどのように扱いますか、また通知タイムラインはどのようになっていますか?
本番システムを開発した他のMAS規制対象事業体からの推薦を提供できますか?
あなたのエンジニアはどこに拠点を置いていますか、またシンガポールのクライアントに対するデータレジデンシーの遵守をどのように確保していますか?

これらの質問に文書とともに具体的に答えられないパートナーは、MAS規制対象業務の準備ができていません。

MAS規制フィンテック:スケール時に何が変わるか

シンガポールのフィンテック企業がMVPからライセンス事業体へとスケールするにつれ、そのエンジニアリングパートナーに対するコンプライアンス要件もそれに合わせて拡大します。ライセンス前のプロトタイプに適した開発パートナーが、決済サービス法のライセンスや資本市場サービスのライセンスの下で運営される本番システムには適さない場合があります。

重要な転換点は、ライセンス承認、外部顧客への製品ローンチ、そしてMASへの通知を必要とする重要なシステム変更です。これらの各時点で、フィンテック企業のCISOまたはテクノロジー責任者は、現行のMAS要件に照らしてパートナーのコンプライアンス態勢を見直すべきです。

すでに規制環境で運営していないパートナーは、通常、監査対応可能になるまでにプロセスと文書化の作業に3〜6か月を要します。これを契約段階での前提として組み込むことで、最悪のタイミングでの遅延を防ぎます。

よくある質問:シンガポールにおけるMAS準拠ソフトウェア開発

シンガポールでMASコンプライアンスがソフトウェア開発パートナーに求めるものは何ですか?

MASコンプライアンスは、ソフトウェア開発パートナーに対して、MASテクノロジーリスクマネジメントガイドラインに沿った文書化されたセキュリティ管理を維持すること、コードレビューと脆弱性テストの証拠を伴う安全なソフトウェア開発ライフサイクルを運営すること、データ取り扱いとアクセス制御をカバーする文書化されたポリシーを通じて第三者リスクを管理すること、そして本番変更とインシデント対応の監査対応可能な記録を提供することを求めます。パートナーはまた、シンガポールの金融データに対するデータレジデンシー管理を実証し、MASの報告要件に沿ったタイムラインを伴う文書化されたインシデント通知手順を持たなければなりません。これらの要件は、社内テクノロジーチームだけでなく、MAS規制対象事業体に代わって本番システムを構築または運用するパートナーに適用されます。

MAS TRMとは何か、それはシンガポールのフィンテックソフトウェア開発にどう影響するか?

MAS TRMとは、シンガポール金融管理局が公開しているテクノロジーリスクマネジメントガイドラインを指します。これらのガイドラインは、第三者パートナーによって開発・運用されるシステムを含む、技術システムについてMAS規制対象金融機関が満たさなければならないリスク管理基準を定めています。フィンテックのソフトウェア開発において、MAS TRMガイドラインは、安全な開発ライフサイクル管理、第三者ベンダーのデューデリジェンス、文書化された変更管理、侵入テスト、事業継続計画を求めています。MAS TRMガイドラインに沿っていない開発パートナーを起用するフィンテック企業は、ライセンス承認を遅らせたり、ローンチ後に監督措置を引き起こしたりする可能性のある規制上のリスクを生み出しています。

MAS規制対象のフィンテック業務のためのソフトウェア開発パートナーに対して、どのようにデューデリジェンスを実施しますか?

MAS規制対象業務のための開発パートナーに対するデューデリジェンスは、6つの領域をカバーすべきです。MAS TRMガイドラインへの整合を示すSDLC文書、比較可能な契約からの侵入テスト記録、特権アクセスの記録とレビュー方法を含む本番アクセス管理プロセス、通知タイムラインを伴うインシデント対応手順、本番システムを開発した他のMAS規制対象事業体からの推薦、そしてシンガポールの金融データに関連するデータレジデンシー管理です。すべての文書は契約前に入手可能であるべきです。規制当局の要求に応じてのみ文書を作成できるパートナーは、MAS規制対象プロジェクトの準備ができていません。

シンガポールにおける標準的なソフトウェア開発と規制対象ソフトウェア開発の違いは何ですか?

規制対象のソフトウェア開発は、スプリント、コードレビュー、テスト、デプロイといった標準開発と同じエンジニアリング実践に従いますが、規制当局が求める3つの層を追加します。第一に文書化です。あらゆる重要なプロセス上の決定は記録され、取り出し可能でなければなりません。第二にガバナンスです。本番システムへのアクセス、デプロイの決定、データ取り扱いは、場当たり的な判断ではなく、文書化されたポリシーに従わなければなりません。第三に監査証跡です。すべての本番イベントは、金融サービスの証拠基準を満たす改ざん検知可能なシステムに記録されなければなりません。エンジニアリングの質は同じです。違いは、すべてがチーム内部で理解されているだけでなく、要求に応じて規制当局に証明可能でなければならないという点です。

海外のエンジニアリングチームがMAS規制対象のフィンテックシステムで作業できますか?

はい、ただし特定の管理下でのみ可能です。MASガイドラインは、MAS規制対象事業体が監督を維持し、パートナーがデータの機密性に見合った管理を実施することを条件に、シンガポール国外からの技術作業を許可しています。規制対象データを扱う本番システムの場合、これは通常以下を要求します。シンガポールの金融データが指定された保存場所を離れることを防ぐデータレジデンシー管理、すべての拠点のエンジニアをカバーする文書化されたアクセス管理ポリシー、拠点に関わらずすべての特権アクセスの監視と記録、そしてデータ取り扱い、インシデント通知、監査権をカバーする契約条項です。規制対象事業体は、これらの管理が整備され機能していることを確保する責任を負い続けます。抜き打ち検査と定期的なレビューは、標準的なコンプライアンス実践の一部です。

シンガポールのフィンテックCISOは、新しいエンジニアリングパートナーをオンボーディングする前にどのような質問をすべきですか?

最も重要な6つの質問は次のとおりです。あなたのSDLCポリシー文書を提供し、それがMAS TRMガイドラインにどうマッピングされているか実証できますか?侵入テストをどのように実施・文書化しており、比較可能なプロジェクトからのサンプル成果物を共有できますか?クライアントシステムで作業するエンジニアの本番アクセスを管理・記録するプロセスは何ですか?インシデント通知のタイムラインはどのようになっており、セキュリティイベントの際の指定連絡先は誰ですか?本番システムを構築した他のMAS規制対象事業体からの推薦を提供できますか?そして、あなたのエンジニアはどこに拠点を置いており、シンガポールの金融データに対するデータレジデンシーの遵守をどのように徹底していますか?これらの質問は、契約締結前に、口頭での保証ではなく文書で回答されるべきです。