Amazon Web Services ブログ

Category: Financial Services

AWS Summit Online 2021 – 金融セッションの見どころをご紹介

今年の AWS Summit はオンライン形式で、5月11日(火)、12日(火)に開催予定です。2つの基調講演の他、事例セッション、パートナーセッション、ビジネスリーダー向けセッション、AWSセッションなど150のブレークアウトセッションをお届けします。金融関連では、金融インダストリーにフォーカスした8つのセッションをご用意したほか、サステナビリティやダイバーシティなど注目のテーマも取り上げています。 まずは金融のセッションについてご紹介したいと思います。今年は、デジタルを活用した新しい金融サービスの開発、変容する社会環境におけるユーザーエンゲージメント、データを活用したビジネス、変化に対応するレジリエンシーなど、現在の金融ビジネスを取り巻く事業課題にフォーカスしたセッション群をご用意致しました。また、マーケットセグメントの観点では、銀行、証券、保険、決済の各領域のお客様にご登壇を頂きます。事例をご紹介頂く各社が、どのように市場環境を捉え、クラウドを活用してビジネス課題を解決しているのか、是非ご参考にして頂けたらと思います。

Read More

AWS における Amazon SageMaker と AWS Data Exchange を使ったアルゴリズム取引

本投稿は AWSのソリューションアーキテクトである Diego Colombatto, Balaji Gopalan と Oliver Steffmann による寄稿を翻訳したものです。 株式取引の大部分が、こちら や こちら の記事で説明されているように、自動化されていることはよく知られています。たとえば、取引戦略を実装するためにアプリケーションや「ロボット」が使用されています。最近の金融サービス業界の新たなトレンドは、取引ソリューション (アルゴリズム取引ソリューション等) をクラウドに移行することです (こちら や こちら の記事で説明されています)。

Read More

ニュース記事 : Morningstar、機械学習の適用を加速するためのグローバル AWS DeepRacer 企業コンペティションを開始

本投稿は AWS 金融事業部門 による寄稿を翻訳したものです。 次の記事は、 もともと Morningstar 社にて発表されたものです。 AWS DeepRacer の最初の社内コンペティションは、世界中の 445 人以上の従業員の機械学習と人工知能の実践学習を推進する。 シカゴ、2019 年 5 月 30 日 /PR Newswire/- 独立系インベストメントリサーチの大手プロバイダーであるMorningstar, Inc. (Nasdaq:MORN) は、今週、全社的にAmazon Web Service (AWS) DeepRacer コンテストを開始しました。Morningstar の技術部門の 35% を含む 8 か国の 445 名を超える従業員が、AWS DeepRacer リーグで約 100 チームを結成しており、機械学習機能を持つ1/ 18 スケールのレーシングカーのプログラミングとそのレーシングを行っています。AWS DeepRacer League Virtual Circuit はすべての開発者がアクセスでき、 amazon.comでレーシングカーを予約注文できます。

Read More

金融業界特集 : Amazon Comprehend

本投稿は AWSのソリューションアーキテクトである John Formento と Syed Shareef による寄稿を翻訳したものです。 編集者注 : これは、金融業界特集の月刊連載の第二回目の投稿です。 Amazon SageMaker ノートブックインスタンスについて説明した第一回目もお読みください。 — 金融業界特集の月刊ブログ連載では、金融業界のお客様がクラウドサービスの利用承認を効率的にすすめるために注力すべき特定のサービスに関する 5 つの重要な考慮事項 を取り上げます。5 つの領域それぞれに対し、特定のガイダンス、推奨されるリファレンスアーキテクチャ、および当該サービスの利用承認プロセスを効率化するために役立つ専門的なコードが含まれます。これらは、お客様の特定のユースケースおよび環境に合わせて変更が必要となる場合があります。 今回の特集では、金融業界のユーザーが大幅に増加した、 Amazon Comprehend (Comprehend Medical を除く)について取り上げます。Amazon Comprehend では、自然言語処理 (NLP) を使用して、ドキュメントの内容に関するインサイトを引き出すことができます。Amazon Comprehend は UTF-8 形式のあらゆるテキストファイルを処理し、ドキュメント内のエンティティ、キーフレーズ、言語、感情、およびその他の一般的な要素を認識し、インサイトを提供します。

Read More

統合取引監視システムでの高度なインサイト

本投稿は Risk Focus社のAlex Rabaev氏による寄稿を翻訳したものです。 統合取引監視システム 2010 年 5 月に発生したフラッシュクラッシュを受け、米国証券取引委員会 (SEC) は、統合取引監視システム(CAT)と呼ばれる包括的な財務データベースの作成を認可しました。CAT とは、ブローカーディーラーと取引所からの米国の株式とオプションに関わるすべてのアクティビティを受信し、保持する中央リポジトリです。 昨年5 月に、ゲストによるブログ記事「 The Consolidated Audit Trail and the Cloud(統合監視システムとクラウド)」を公開しました。 記事では、AWS PrivateLink を使う事で、AWS ブローカーディーラーが CAT レポート可能なデータを Virtual Private Cloud(VPC) から Financial Industry Regulatory Authority(FINRA) の VPC に転送する方法について説明しています。AWS PrivateLink を使用すると、パブリックインターネットを経由することなく、安全な方法で実行できます。 このブログでは、CAT レポートと例外処理に関連する膨大な量のデータを分析する方法について説明します。AWS コンサルティングパートナーである Risk Focus が開発したソリューションである CATalyticsに焦点を当てます。AWS 上に構築されたオープンソースのダッシュボードにより、ユーザーは例外の解決、質問への回答、CAT レポートに関する問題の根本原因の特定を行うことができます。

Read More

大手金融機関におけるセキュリティ・コンプライアンスのためのイベント管理

本投稿では、商業銀行として米国で Top 25 内にランクインしている金融機関であるBBVA USAが、AWS サービスを使用して大規模なイベント管理の仕組みを実装し、クラウド環境に関連する変更イベントを一元管理し、アクションを自動化した方法について紹介しています。一般的に、モノリシック環境でのセキュリティ・コンプライアンスは、管理・監視対象となるインフラストラクチャが少ないため、監視と実施が比較的容易です。それが多くなったとしても、インフラストラクチャをコード化すれば、民主化され分散化されたアプローチによって、コンプライアンスの見落としなく構成の差分管理(ドリフト)と追跡処理を環境に取り入れることができます。 インフラストラクチャの正常な状態を識別し、そこから外れた違反状態を把握することにより、インフラの状態の可視性が確保され、必要に応じて自動修復によって遵守を強制させることが可能になります。このために、セキュリティイベントの通知やベースラインとなる構成定義といった機能を使うことができます。

Read More

re:Invent 2020をフル活用する!―金融機関様向けガイド

AWS re: Invent は通常、ラスベガスのいくつかの会場では聴講者が多すぎては入れないケースがありましたが、今年は全て、無料でバーチャルのイベントをお届けします。今年のカンファレンスは、過去にも増して最大規模となる予定で、11月30日より、5つの基調講演、18のリーダーシップセッション、500を超えるセッションを開催し、金融サービス業界向けに、お役に立てるセッションも数多くご用意しております。AWS の専門家や金融サービス業界の画期的なリーダーが、クラウドテクノロジーを使用してお客様の為にビジネスを変革、革新している様子をご覧ください。   re:Inventに参加したい方は以下のステップを参考にして下さい: ·      まずはre:Inventに登録。登録すると、全てのセッションにアクセスできるようになります。 ·      金融機関様向け参加者ガイドで、公開予定のすべての金融サービスセッション、手続きやその他ハンズオンアクティビティを含む情報をご参照ください。 ·      セッションカタログを定期的にご確認ください。最新の情報を反映するために継続的に更新していきます。   re:Invent 2020における金融機関 現在の特異な環境下においても、企業や消費者は、将来に向けて新しいことにチャレンジし成長することを学んできました。AWS のクラウドソリューションは、いろいろな形で金融サービス企業を支援しています。持続可能なスケーリング、アプリケーション開発のモダナイズ、安全性とレジリアンシーの向上、データの活用をおこないながら、新しい市場オポチュニティの探索、顧客エンゲージメントの変革をおこなっています。これらの金融サービス企業は今後の5~10年後を見据えたクラウド展開を推進されています。   金融機関向けセッション AWS re:Inventでお会いできるのを楽しみにしています。下記は、金融トラックのセッションです。 FSI201: Financial Services: Navigating change while facing forward, with HSBC ―変化に対応しながら前進するHSBC  (Dec 2, 2020 | 4:30 AM – 5:00 AM JST) パンデミックを通して、金融機関は消費者や企業のニーズを満たすために新しい技術を活用してきました。HSBC と AWS とのコラボレーションで、どのような新しいソリューションを提供し、業界の継続的な変革を推進しているかをお話しします。 スピーカー: Dinesh Keswani, Group CTO, HSBC Frank Fallon, VP of Financial Services, AWS […]

Read More

セキュリティの実践とベストプラクティス -日本銀行様『クラウドサービス利用におけるリスク管理上の留意点』によせて-

本Blogは、クラウドにおける新しい常識”new normal”を考えるBlogの第五弾です。
多くのお客様は、より安全にサービスを提供するために多様なセキュリティを組み込み、また規制要件を満たしていくことで組織としての説明責任を果たそうとしています。
日本銀行様では、多くの金融機関のお客様がよりクラウドを活用したイノベーションをおこし、サービスを向上するために『金融システムレポート別冊』として「クラウドサービス利用におけるリスク管理上の留意点」(以下、本別冊とします)を発表しました。本Blogでは本別冊に基づき、組織がセキュリティを実践するために必要な考え方のいくつかを示してみたいと思います。

Read More

AWSを通じて日本取引所グループ(JPX)のarrownetにアクセスをする

“undifferentiated heavy lifting”という言葉をしばしば聞くことがあると思います。これは、競合他社との差別化にはなりえない作業にリソースを大量に消費することを言います。たとえば、サーバを構築し、OS にセキュリティパッチを適用するようなことです。このような作業は、より付加価値が高い製品やサービスを生み出すための活動から、ヒト・モノ・カネを奪い去ります。AWS では、お客様起点の重要な役割として、作業を簡素化し、自動化できるクラウドによるソリューションによって、開発者を”undifferentiated heavy lifting”から解放できるように支援しています。 金融業界では、過去20年間で大きな進歩を遂げています。たとえば、キャピタルマーケットの領域では、クラウドによるマーケットデータの活用により、トレーディングチームはリアルタイムでより良い洞察を導き出し、増え続けるデータからリスクをより効率的に計算できるようになりました。 しかしながら、いくつかの企業にとって、”undifferentiated heavy lifting”はまだ存在しています。それらの1つは、金融機関が規制機関や取引所によって設定された規制や業界ルールを遵守しなければならないことに関連しています。市場参加者は、これらの市場ルールを遵守する必要があり、遵守しない場合はペナルティを受ける場合もあります。 金融業界は、進化し続ける要件の複雑さと細分性が高まっている世界で最も規制の厳しい業界の1つです。しかし、金融機関がコンプライアンスに投資するすべてのリソースについて、多くは義務から機会への移行を行えていません。言い換えれば、ほとんどの金融機関では、同業他社との差別化を図るのではなく、ビジネスを行うためのコストとして、依然として規制やコンプライアンスを捉えています。 野球で例えるならば、プレイヤーはゲームのルールに従わなければなりませんが、優れたプレイヤーは、常に個人とチームの両方のレベルでパフォーマンスを改善するために戦略と戦術を使用しています。同様に、企業は規制要件に対応する必要がありますが、合理化、自動化、コスト効率の高い方法でそれに対応する必要があります。 このブログでは、日本取引所グループ (JPX) が AWS でどのように市場参加者にとってより良い顧客体験を生み出しているかをお話します。JPXは、これまでネットワークへのアクセスに関連していた”undifferentiated heavy lifting”を排除することで、市場参加者が新しいサービスのテスト、構築、立ち上げに向けてリソースを再利用できるようにしています。 JPXは、メンバー企業のクラウドでの市場アクセスを強化 2020年5月、JPX は市場参加者が AWS Direct Connect を介して、売買システムや清算決済システムなどにつながる高信頼ネットワークである arrownet にアクセスできるようにしました。 以前は、会員企業がarrownetに接続したい場合、JPXと自社のオフィスやデータセンター間に専用線を注文し、そのうえでネットワーク構築やセキュリティ対策を実施する必要がありました。このネットワーク構成は、変動する市場に迅速に対応するための信頼性と安定性が必要で、さらに十分な通信容量を提供する必要がありました。回線が接続されると、市場参加者は24時間365日体制で監視し、ハードウェア障害に対応するために人的リソースも投下する必要がありました。また専用線ベンダー側の監視にも、これらの重要なタスクのための人件費とサポート費も付属しています。つまり、arrownetへの接続は、利用者が長年にわたって対応してきた”undifferentiated heavy lifting”とも言えます。 JPXは、市場参加者からフィードバックを取り入れ、arrownetをクラウドに拡大し、市場参加者のアクセスを簡素化しました。市場投入までの時間が短縮され、マーケットからのデータを AWS 環境で扱うことで、マーケットの変動に対してオンデマンドで拡張できるようになります。 JPX は AWS Direct Connect の仮想インターフェイスを提供します。これにより、会員企業は短い期間でarrownetに接続して、テストすることができます。その結果、AWS の利用者は、以前は専用回線接続で直面していた”undifferentiated heavy lifting”な作業をすることなく、クラウド環境でマーケットからのデータを受け取ることができます。 現在の会員企業がこの合理化されたマーケットアクセスの恩恵を受けるだけでなく、FinTech スタートアップも恩恵を受けることができます。多くの Fintech スタートアップは AWS のサービスを使用しているため、彼らの既存の環境をより効果的に活用するには、クラウドネイティブ接続が必要でした。マーケットへの迅速なアクセスができるようになったFintech スタートアップは、新製品やサービスの市場投入までの時間をさらに短縮することができるでしょう。 現在、AWS Direct Connect により、JPX […]

Read More

クラウドサービスの評価を最適化する方法

本投稿はワールドワイドで金融業界を担当しているプリンシパル・テクニカルプログラムマネージャーの Jennifer Code による寄稿を翻訳したものです。 私の同僚の Ilya Epshteyn が、 金融機関が機密性の高いデータのためにAWSサービスを承認する方法 というタイトルのブログでご紹介したように、金融業界では一般的にクラウドサービスの正式な評価プロセスが存在します。これらの評価プロセスは深さや幅に関しては様々ですが、いずれのプロセスも、業界の期待とテクノロジーリスク管理の健全性を確保しつつ、ビジネス要件を満たすのにはどのクラウドサービスが最適かを決定しようとするものです。このブログでは、クラウドサービスに対する新たな評価プロセスを構築する、または既存の評価プロセスを最適化する際に役立つシンプルなガイダンスを提供します。 私は、お客様と頻繁に会ってお客様のガバナンスとクラウドの評価プロセスについてディスカッションをしますが、その中でよく耳にするテーマがいくつかあります。1つ目は、評価プロセスが正式に存在する場合であっても、オーナー不在の場合が多く、結果としてそのプロセスが達成すべきビジネス上の成果を必ずしも理解しないまま、チームがプロセスに従っているという問題です。強いオーナーシップがなければ、参加者と評価範囲に一貫性が保てません。また、時には、構造化されたフレームワークではなく、個々の専門知識とベストエフォートに依存しているため機能性に差異が生じている場合もあります。最後に、お客様は、ほとんど例外なく、知識の共有を進めつつ、繰り返し学ぶことによって、評価プロセスの質を一気に向上させる方法があるのではと感じています。 正式なクラウドサービス評価プロセスがとても重要なのはなぜでしょうか? 金融サービス会社は、テクノロジーリスクの監視を証明するという、共通の規制上の義務を負っています。従来、企業のリスクフレームワークは、サイロ化された「3 つのラインによる防御」または (3LoD) で構成されていました。第一のラインはリスクの所有者としてコントロールを実行するビジネス / 運用担当者、第二のラインはリスクのモニタリングとコントロールの評価を行うリスク管理担当者、第三のラインは独立または内部監査人、またはリスクアシュランス担当者で構成されています。これらの 3LoD はそれぞれ、テクノロジーリスク、一般的な社内のポリシーの収集、ならびに他の防御ラインによって行われた一連の評価・監査に合わせて自チーム内で文書化された手順についての責任を負ってきました。 この既存の企業リスクフレームワークにクラウドの評価プロセスを組み込むことで、組織は重要な技術上の意思決定がどのように行われたかを適切に証明できるようになります。また、リスクがどのように評価され、軽減されるか、コントロール環境の強さがリスクアペタイトにどのように適合しているかといった点を、クラウドベースのサービスの微妙な差異に焦点を当てつつ説明できるようになります。 クラウド評価を最適化するためのヒント 金融サービスのお客様の期待を念頭に置き、お客様がクラウド評価プロセスを構築または改善するために実行できる3つのアクションを提案します。 ガバナンス体制の正式化。ガバナンス体制が正式に確立されていない場合、金融サービス機関がとるべき最初のステップは、クラウドのガバナンスとコントロールに関してエンドツーエンドの責任を担うC-レベルの経営幹部を任命することです。 プラットフォーム コントロールの優先順位付け。クラウド評価を策定する際に、優先順位と要件について、クラウド・プラットフォームとビジネス・アプリケーション機能の区分を取り入れます。セキュリティとレジリエンスのためのプラットフォームレベルのコントロールを最初の優先事項として重要視します。ビジネス・アプリケーションの機能に視点が移った時に、クラウドプラットフォームから継承されたコントロールに基づいて評価を調整できるようになります。 継続的な改善の組み込み。 知識共有と継続的な改善は、Day 1から明確に優先されるべきです。積極的な透明性があることにより、コントロールが構築され評価が行われる際に、3つの防御ラインすべてにわたっての信頼が築かれることが期待されます。意識的かつ積極的な共有によって、コントロールが設計されており、最初の本番ユースケースに対しても効率的に実行することができるという自信につながります。 AWSの使用量と専門知識が増えるにつれて、コントロールの強化と適用範囲の継続的な改善も容易になります。 ガバナンス体制の正式化 重要な最初のステップはクラウドのガバナンスに対する完全な説明責任を持つ適切な Cレベルの経営幹部を特定することです。この個人は、はじめにクラウドのガバナンスとコントロールのトーン設定を行い − クラウドの評価、使用状況、および継続的なモニタリングのための構造とプロセスを構築する責任をもちます。重要なのは、組織全体の専門知識を活用して、十分に制御されながらアジリティのある環境を確立するよう促す意欲のある、強力でポジションの高いリーダーを任命することです。 そのガバナンスのリーダーは任命され次第、評価プロセスを形成する機能横断的な構造、成文化されたポリシーと必要となるガバナンスプロセスを正式化し、現在進行中の評価のサポートをしなくてはなりません。私の経験では、正式なガバナンスの枠組みに支えられた多様な専門知識を活用できるバーチャルなチームが最も効果的です。 効果的なクラウドガバナンスの考慮事項 効果的なクラウドガバナンスの目標を定め、専門知識を正当に評価する企業全体のクラウド戦略 は、導入と使用状況を測定しながら時間をかけて構築します。 クラウドガバナンスに責任のある経営幹部を任命、従事、およびコミットすることで全体的なガバナンス構造に統合し、継続的なモニタリングを行います。 知識が豊富で 参加を約束できる(3 つの防御ラインにまたがった)リスクとコントロールのステークホルダーをクラウドのガバナンス活動における正式な参加者 にします。 企業のガバナンス フレームワークとプロセスに準拠することで、クラウドイネーブルメントチームの存在を明確にします。 定義されたプロセスを組織に伝達するとともに、承認されたクラウドサービスのみを利用していることを確実にする自動強制機能を使用します。 プラットフォーム コントロールの優先順位付け 私と顧客とのやり取りでよく見られたパターンは、クラウドサービスを評価するにあたり、たった1つのアプローチを作成し、それを全てのパターンに当てはめようとするやり方です。これは典型的に、各サービスを個別に評価する形式をとり、多くの場合、体系的に完成された詳細なチェックリストを伴います。 なぜこれが理想的ではないのでしょうか? 第一に、これは各サービスへの脅威は同等であることを前提としています(したがって、同じ評価が必要なコントロールを決定する適切な方法とされます)。第二に、このタイプのアプローチでは、評価者が能力または機能により区別することは認めていません(たとえば、データを中心としたサービスとコンピューティング サービスの違いを考慮しません)。最も重要な点は、既存の統制基盤を考慮していないことです(したがって、追加のコントロールの必要性を過大評価してしまう可能性があります)。 私が見てきた中で最も効果的だったのは、交渉不可能な基盤を確立した上で、環境、データの機密性、ビジネスの重要性など、他の要因に基づいて必要なコントロールを追加する、段階的なコントロール フレームワークです。この区分けによって、不適切なレベルのリスクを発生させることなく、実験を行うことができます。具体的には、すべてのデータタイプ、すべての環境において最初から予防的統制でなければならないコントロールもありますが、その他のコントロールではモニタリングをサポートすることによって、発見的統制から始めることが許容できるかもしれません。適切にコントロールされたイノベーションが目標です。 […]

Read More