Table of Contents
金融サービスセッション: みんなの銀行・セブン銀行・ au じぶん銀行
この文字起こしは、2023 年 12 月 12 日に開催された Authlete Customer and Partner Meetup 2023 のパネルディスカッションです。 みんなの銀行さま、セブン銀行さま、au じぶん銀行さまに、ATM、BaaS、Mobile を起点とした各行のビジネス戦略、CIBA、FAPI 実装に踏み切ったポイントや課題、そして Authlete 導入の効果についてお伺いしました。
登壇者
- パネリスト
- 株式会社みんなの銀行 / ゼロバンク・デザインファクトリー株式会社 Development Division エンジニアリングマネージャー 穴井怜氏
- 株式会社セブン銀行 金融ソリューション部 部長 紙中加代子氏
- au じぶん銀行株式会社 執行役員 IT 本部長 都木良和氏
- モデレーター
- 株式会社 Authlete ソリューション戦略担当 VP 工藤達雄
はじめに
工藤 (Authlete): パネルディスカッションには、弊社のサービスを使っていただいている銀行の皆様にお集まりいただいております。
今日ご登壇していただいている皆様をご紹介します。左側から、みんなの銀行、ゼロバンク・デザインファクトリーの穴井さん、セブン銀行の紙中さん、au じぶん銀行の都木さんです。そしてモデレーターは、わたし工藤が務めさせていただきます。
まず皆様に、自己紹介、会社と個人のご紹介をしていただき、その後いろいろな観点から、とくに銀行業界、プラス API、プラスなぜ Authlete かを、ディスカッションしていければと思っております。
自己紹介
みんなの銀行
株式会社みんなの銀行 /ゼロバンク・デザインファクトリー株式会社Development Divisionエンジニアリングマネージャー穴井怜氏
穴井 (みんなの銀行): 株式会社みんなの銀行、及びゼロバンク・デザインファクトリーの、穴井と申します。
みんなの銀行は、「みんなに価値あるつながりを。」をミッションに、2021 年の 5 月にサービスを開始しました。
みんなの銀行は、ふくおかフィナンシャルグループの傘下でして、日本初の、店舗を持たないデジタルバンクです。2023 年 の 5 月で 2 周年を迎えまして、2023 年 9 時点で全国 80 万口座まで広がっています。
かんたんな自己紹介ではありますが、あらためて、穴井と申します。元々 SIer からエンジニアのキャリアを始めて、自社サービスの開発、および EC サイトだとか Web メディアの構築開発の経験から、金融や決済領域に興味を持ちまして、いまのゼロバンク・デザインファクトリーに、2022 年 2 月に入社しました。
現在はみんなの銀行の BaaS 事業に携わり、非金融の企業様に金融機能を提供する API を開発しています。わたしは主にエンジニアリングマネージャーとして、開発のマネジメントと、お客様や提携先様に対する開発のサポートや導入支援を行っております。
セブン銀行
株式会社セブン銀行金融ソリューション部部長紙中加代子氏
紙中 (セブン銀行): セブン銀行 金融ソリューション部の紙中と申します。
セブン銀行は ATM サービスを中心とした、流通グループの銀行になります。2001 年に開業し、いま 20 年ちょっとになります。国内に 2 万 7000 台の ATM を、セブン＆アイグループの各店舗の他、駅や商業施設といった、生活の身近な場所に置かせていただき、現金入出金の他、最近は QR 決済のチャージポイントとしてもご活用いただいています。
ATM 事業の他、セブン銀行自身が銀行口座を提供しております。その口座を使った金融サービスにも力を入れていこうとしていまして、現在、事業の多角化にも取り組んでいる状況にございます。
わたくし自身ですが、中途入社で、2007 年にセブン銀行に入社しまして、ずっと、口座事業のシステム開発プロジェクトの、推進に取り組んできておりました。2016 年頃から、IT 部門の中の DX 推進の担当というかたちになりまして、銀行 API の開発や内製化を進める取り組みを立ち上げて、アジャイル開発の導入推進などを担当し、現在に至っております。
au じぶん銀行
au じぶん銀行株式会社執行役員 IT 本部長都木良和氏
都木 (au じぶん銀行): au じぶん銀行の都木と申します。
まずかんたんに、au じぶん銀行の説明をします。みんなの銀行さんとセブン銀行さんのちょうど真ん中ぐらい、2008 年に、KDDI と当時の三菱東京 UFJ 銀行の出資でできた銀行です。通信と金融を融合させて新しい銀行サービスを提供しようという思いの中からでき上がって、2023 年 で 15 年目になります。
コンセプトとして、スマートマネー構想と書いています。生活の中心となったスマートフォンを通じて、様々な金融サービスを提供するという考え方です。実際ここに書いてあることは、多くの銀行のサービスを使いながら実現されているとは思うのですが、その選択肢のひとつに入れていただけるといいな、なんて思っています。
規模について、2023 月 の 3 月に 510 万口座を超えました。これからもどんどん口座数を伸ばしていかなければならないと考えています。しかし口座数が増えると、今回導入している Authlete のところを通過するトランザクションも増えるということで、今日の日経さんの話は、興味深く聞かせていただきました。
自己紹介です。いろんな会社を転々とした後、2012 年に au じぶん銀行に入り、ふた桁を超える年月在籍しています。その中で、IT 本部の IT 開発部に在籍しながら、勘定系、周辺系問わず見てきた結果、IT 本部長という役割を拝命しており、人生というものは予測のつかないことばかりだなと思いながら、いまこの場に立っているところでございます。
本日のトピック
工藤 (Authlete): 今日のトピックとして 4 つ考えています。
まず、銀行と API ということで、そもそも銀行業界にとって API はどういう位置付けなのか、どういうことが求められているかを、各パネリストの方にご紹介いただきたいのが 1 点目です。
2 点目として、API 基盤の確立にあたって、そもそもの目的とか、要件とか、その確立に至った最初の課題といったところを、各銀行さんはいろいろなフェーズやターゲットがあるかと思いますが、そういった部分を深掘りしていければと思います。
3 点目として、Authlete を選定していただいたということで、その決め手となったポイントですとか、導入効果を伺います。
最後に今後の展望ということで、進めていければと思っております。
銀行と API の関係
工藤 (Authlete): まず、銀行と API の関係です。そもそも、「なぜ銀行が API か」というのは、もういまでは当たり前になっている、と言っていいんでしょうか。というのは、金融業界の中でも銀行は非常に固いイメージがあり、API の公開とは相容れない部分があるように思います。
銀行機能の提供
工藤 (Authlete): そもそも、なぜ銀行が API を公開することになったのかといったところを、背景を含めてお話していただけますでしょうか。
都木 (au じぶん銀行): もともとイギリスで、銀行の機能を API として提供することが、先行して進んでいました。そこから遅れて日本でも、銀行の機能を様々な非金融事業者に対して提供し、フィンテックなどの産業を新しく立ち上げていく狙いがあったのではないかと、当時を振り返りながら想像しています。
とくに銀行の金融の API は、多くの事業・監督省庁などから公開される情報を見ながら仕事をするのですが、API の資料も業態ごとに違うとか、方針のみに特化して記載されており資料の更新頻度も低く、最新情報は自発的に取りに行く必要があるなどで我々も迷子になっているところは、多分にあると思います。
ただそのような中で、BaaS であったり、FinTech 企業への API 提供であったりと最近よく耳にすることも増えてきて、銀行がその機能を API として切り出していくことに、誰も驚かなくなってきたのかなと思っております。
一方で周囲の状況を見ながら必要最低限の API を作ってきたこともあり、今少し戦略的に拡充しておくべきであったと振り返ってもいます。
モバイルへの注力
工藤 (Authlete): API を公開するという方向と、あと、とくに今回出ていただいている 3 社の銀行さんにおいては、モバイルへの注力などがあると思います。外部に開放する API とは別に、モバイル向けのような自社で使う API については、どのような必要性を感じられましたか?
紙中 (セブン銀行): 当社も、モバイルに注力していきたいという方針と、それに合わせてクラウドをしっかり活用していこうという動きが相まっていました。
モバイルと ATM の掛け合わせのような新しいことをやろうと思うと、レガシーな接続手段だとなかなかやりたいことも実現できませんし、現在のテクノロジーの恩恵も受けにくいところがあります。
そして、自分たち自身が API を求めるようになってきたことも、動きとして大きかったと思います。
API ファースト
工藤 (Authlete): みんなの銀行さんの場合も、初めから「API ファースト」があったと思うんですよね。その時にどういったことを考えましたか?
穴井 (みんなの銀行): 当初からみんなの銀行は、既存の銀行の機能だけでなく、BaaS の立ち上げを考えていました。なので、API の提供・公開を前提にシステムを構築していきました。
工藤 (Authlete): その中で、たとえば銀行業界では参照系 API とか更新系 API とかがありますが、その進め方とか、サービスの展開とか、どのように考えましたか?
穴井 (みんなの銀行): 弊社は、小さくスタートしていこうということで、まずは必要な銀行機能を小さく作り、その後徐々に参照系の API を公開し、その次に更新系の API を公開するような、かなり段階を踏んで前に進めていきました。
標準への対応
工藤 (Authlete): API 公開をどんどんやっていく中で、一方で規制というか業界自主規制というか、そういったルールとの兼ね合い、あるいはどうやって折り合いをつけるか、どうお考えですか?
都木 (au じぶん銀行): 関係省庁より出ていたガイドラインは、安全に参照系 API と更新系 API を提供していこうというものであったので、ブレーキをかけるものではないと思います。
一方で、どの銀行も同じようなインターフェースや項目を用意しないと、それを利用する企業の方々が、個別の銀行ごとに実装しなおさなければならず、大変です。当時、電子決済等代行事業者のみなさまよりガイドラインになるべく合わせてほしいという要求もありました。
当社が有していた旧来の参照系 API とガイドラインとを比して、不足項目があるとガイドラインに合わせるための実装工数が必要になります。その点について、当社内の投資判断を行う上で「本当にそれは必要なのか」といった議論がなされました。
工藤 (Authlete): よく聞くのは、API を公開しなさいというお題目はあるけど実際の細かいところがまだ決まってないとか、電文仕様はなんとなく決まってるけれども微妙にレガシーを引きずっている部分があるとかいったことです。我々からすると、少なくとも OAuth 2.0 とかの部分はしっかり決めるべきと思っていたんですよね。
そういった、どこまで自分たちで考えて、どこまで標準を取り入れるかといった部分で、気になったことはありますか?
紙中 (セブン銀行): いま様々なシステム間での新規接続を検討する際に、OAuth 2.0 準拠は当然と思って話をしていると、そこから齟齬があり、まず OAuth 2.0 に準拠するかどうかから議論になることがあります。
これまでの API 活用の経験から、これくらいのセキュリティは担保しとかないと危険だよね、レガシーな接続方式はやっぱり採用できないよねとなるので、そこら辺の折り合いだとか、新しい難しさにぶつかることはあるかなと思います。
API 基盤確立の目的・要件・課題
工藤 (Authlete): 今回出ていただいた御三方は、始めた時期や、その前段の前提事項もけっこう違う部分があります。当初の目的や、その際に何を見据えていたかなどをお伺いします。
オープンイノベーション
紙中 (セブン銀行): 2017年、改正銀行法があって、オープン API に取り組まなきゃいけなくなりそうだという空気がありました。また同時期に社内でオープンイノベーションの動きが活発になり、ビジネス部門の人間が、新規のビジネスの種として API に注目しました。
わたしたちの中で、そこの経験がある人はいませんでした。そこで、IT 部門とビジネス部門、あとベンダーさんも一緒に、FINOLAB に入っていた川崎さんのところを訪問しました。そして数時間勉強させていただいて、OAuth とは何かというところから、実装の難しさまで、みっちり教え込まれたのが一番最初でした。
どちらかというと、オープン API よりも前に、API を使ってビジネスをしたい、というのが先行していました。経路としては異例ですが、先に更新系の API を提供してビジネスの実績を作った後に、オープン API というかたちでしっかり基盤を作っていこう、というのが当社の流れでした。
BaaS の推進
工藤 (Authlete): みんなの銀行さんでは、API が BaaS ビジネスや B2C の中でどう活用されるかについて、どのようなイメージを持っていたのでしょうか。
穴井 (みんなの銀行): 弊社を立ち上げる時、ヨーロッパなどの海外では、BaaS のビジネスがすでに始まっている状況でした。そのため、ゼロから銀行を始めるのであれば BaaS をやるぞくらいの勢いで、かなり確信を持ってやっていたところはあるかなと思います。
「Alexa 対応」からの高度化
工藤 (Authlete): au じぶん銀行さんでは、まず2017年から2018年に API を作られて、今回、2023 年に更改されています。当初の目的と、今回の更改のきっかけは、どういったものでしょうか。
都木 (au じぶん銀行): 当初は、さきほども出た改正銀行法の関係もありつつ、私たちにはその前にAmazon Alexa 対応がありました。Alexa 上でお客さまの残高をお知らせするプロジェクトがあり、Alexa と OAuth ベースで接続する必要がありました。ただ本取り組みに対し潤沢な予算を投入することもできないので最小構成で目的を実現するべく独自実装しました。そのころは、OAuth 2.0 ベースの FAPI っていうのが世の中にあるが、なかなかに難しい内容だね、といった会話をしていました。
ところが、時代が進み、au フィナンシャルグループ内の会社に対しても残高などの情報を提供しているところもありますし、他にもいろいろな機能を外に対して提供していく可能性も否めない。その様な中、我々がこのまま独自実装で FAPI に追随できるのだろうかと考えたところ、これは無理だなとすぐ答えが出ました。悩むまでもなかったです。
答えが出てしまえばかんたんで、いまある基盤に固執せず腹を括って新しい API 基盤を作ろう、というのがきっかけでした。
FAPI / OAuth の採用
工藤 (Authlete): いま FAPI というお話がありました。標準仕様を追いかけるというところでは、どの仕様を採用するか、それをいつやるかは、たぶん問題だと思うんですよね。基盤更改の際に FAPI を選んだのは、どのような理由からでしょうか。
都木 (au じぶん銀行): 最初にフルスクラッチで小さく作ったときから、「FAPI というものがあるが、更新系 API のセキュリティを担保するためには、この規格に沿っておけば独自に難しいことを考えなくても安心なのではないだろうか」という思いが、わたしの中にありました。
工藤 (Authlete): セブン銀行でも、OAuth 2.0 を選んだのは、それが標準だからということでしょうか。
紙中 (セブン銀行): 最初の川崎さんの勉強会のインパクトが本当に強かったです。正しい API の実装は大きなテック企業さんでも難しい部分があり、それが即セキュリティホールになる事例を、次から次に紹介されました。その中で OAuth 2.0 をご紹介いただいて、すごく納得感がありました。参加者が採用を決定するメンバーだったこともあり、そこはすんなりと学びになりました。
API ゲートウェイ導入の課題
工藤 (Authlete): FAPI はともかく、OAuth はいろんなソリューションに入っている機能だと思うんです。今回皆様のところでは API ゲートウェイを導入されていて、そこに OAuth 2.0 機能が入っています。でも、入っているにも関わらず、それは使われていません。API ゲートウェイの課題は何だったのでしょうか。
みんなの銀行さんは Google Cloudの Apigee をお使いになっていますが、Apigee はいろいろカスタマイズというか、後から追加拡張ができますよね。その機能を使って、がんばって FAPI を作る方向もあったかと思うのですが、なぜそうしなかったのでしょうか。
穴井 (みんなの銀行): 認可にかける開発コストを下げたいところがありました。弊社は立ち上げでゼロから作っていたので、素早くスタートしたかったんです。
なので、開発コストを下げられる外部ソリューションを検討したところ、Authlete さんが出てきて、これを使えばかなりコストが安く、かつ早く導入できるんじゃないかと考えました。
工藤 (Authlete): セブン銀行さんは Azure API Management を使われていますが、それも同じような理由でしょうか。
紙中 (セブン銀行): API 管理自体は Azure API Management を使って、認証は既存のインターネットバンキングの認証基盤を使いたい、というのがありました。
認可のところは実装の難易度もありますし、当社にとっても、急いで導入しないと、スクレイピングベースでのアクセスの急増で基幹系システムのリソースがひっ迫し始めているというのが見えてきていたので、開発のスピードも加味すると、そこは Authlete さんの力を借りるのがベストな選択なのかなって判断だったと思います。
工藤 (Authlete): au じぶん銀行さんは MuleSoft を使われていますけど、それも、クイックに標準に従うために Authlete というところですか?
都木 (au じぶん銀行): MuleSoft を我々が入れた時の目的のひとつは、既存のシステムが密結合になっているところを疎結合にしたいという、EA 改革でした。そのためのソリューションとして MuleSoft を選定しました。認証は勘定系側の認証基盤を使うことにしました。
その上で、認可の機能が必要になりましたが、前回のように独自に作りたくはありません。そんな想いを抱えながら検討していく中で、Authlete が候補になりました。
Authlete 選定の決め手
工藤 (Authlete): Authlete の選定に至ったポイントを、次にお伺いしようと思います。なぜ Authlete なのかという経緯を、まず、みんなの銀行さんからお話しいただけますでしょうか。
専門家に任せた方が安全
穴井 (みんなの銀行): みんなの銀行では、認証基盤も認可基盤もゼロから作る必要がありました。
認証基盤は、たとえば外部にお願いした場合、個人情報を外部に渡さなくてはいけない点がリスクでした。なので認証基盤は自分たちで作るべきだということで内製しました。
一方、認可基盤は、世界的な標準やセキュリティ水準が、どんどん進歩していきます。それを追いかけるのには、それなりの体力と、技術的な能力が必要になります。そこは専門家に任せた方が、自分たちでやるよりは安全だろうと考えました。このニーズを満たしているのは、ほぼ Authlete 一択だな、となりました。
自分たちに必要な機能を探索
工藤 (Authlete): au じぶん銀行さんが Authlete を採用したのは 2022 年ですが、他の銀行が Authlete を採用していたことを意識されたことはありましたか?
都木 (au じぶん銀行): 正直、他社が導入していることには、あまり重きを置かなかったです。FAPI を含め API を取り巻く情勢の動きが早いので、自分たちにとって本当に必要な機能はどれだろうと、自分本位の目線で選択していました。
Authlete については、LinkedIn 経由で知りました。工藤さんが前職の時に LinkedIn でつながりましたが、そこでは常に工藤さんがアピールされるわけです、Authlete の記事を。強く印象づけられました。
熱量の強さ
工藤 (Authlete): セブン銀行さんも、さきほど川崎の話をされていましたが、とくに強烈なエピソードなどはありますか。
紙中 (セブン銀行): 勉強会には、ビジネスのサイドの、IT の知識がまったくゼロみたいなメンバーも一緒にいたんですけど、川崎さんはそんなことはおかまいなく、どんどん話が深いところに入っていきました。その熱量も含めて、すごい本当に飲み込まれました。いまでもその光景を覚えています。
他システムとの親和性と、開発コストの低減
工藤 (Authlete): いろいろなきっかけがあって知っていただいたということで、自社で開発するよりも、最新仕様への追随や、セキュリティの担保が響いたのだと理解しました。ただ、たとえば FAPI 対応とか OAuth 2.0 対応とかについては、他にもいろんなソリューションがあったと思います。その中で Authlete を選んだのは、どういった理由でしょうか。
穴井 (みんなの銀行): FAPI に準拠していることの他にも、いくつか要件がありました。弊社は Google Cloud でシステムを構築しているので、その Google Cloud との親和性の高さや、また可用性を担保するためのマルチリージョンでの稼動などが挙がっていました。
あと、開発コストを極力下げたいということで、他社と比較して、他の製品だと一定の開発コストがかかってしまうところがありました。そういったところを加味して Authlete を選びました。
API ゲートウェイとの組み合わせ
都木 (au じぶん銀行): まず、MuleSoft を使うかどうかも含め、様々な組み合わせを検討していました。その過程や評価していった結果、MuleSoft と Authlete との組み合わせで行くところまでは、銀行側で決めました。
実はそこからが難産でした。多くの会社さんに「MuleSoft と Authlete の組み合わせで提案をしてほしい」とお願いし、「うちは経験がないからダメです」と断られに断られ、プロジェクトの立ち上げが遅延し、当時の責任者にはちょっとかわいそうなことをしたなと思っています。
ただ、組んだ会社さんは Authlete の開発経験が無かったのですが、けっこう短い期間で実装できました。そのことから、やはり導入しやすいソリューションなんだなと、強く感じました。
導入の容易さ
紙中 (セブン銀行): 当初は、Azure の利用経験がそれほどある状態ではありませんでしたが、1〜2 ヶ月間の検討の後、開発を始めてからリリースまで、半年前後だと思います。
導入効果
サービス開発への注力
工藤 (Authlete): この中で一番長く使っていただいているのはセブン銀行さんになりますが、ここまでどういう効果が得られましたか?
紙中 (セブン銀行): 認可の重要な部分を Authlete さんにお任せできるところが大きいです。やはり金融のサービスですので、セキュリティは非常に力を入れていかなくてはなりませんが、そこをお任せして、その分をサービス開発に振り向けられます。適切にリソースを配分し、全体的に、新しいことをやっていく上でのハードルを下げていく効果が、一番大きいかなと思います。
新たな標準仕様の活用
工藤 (Authlete): 新しい挑戦というところでは、多分 Authlete 自体が進化している部分もお役に立っているのではないかと思うんですよね。その点ではいかがでしょうか。
穴井 (みんなの銀行): まず一点は、Authlete が FAPI 2.0 に追随して対応しているので、みんなの銀行としても即座に対応できることがあります。
また、弊社の BaaS の API として、本人確認 API を提供しています。みんなの銀行は、eKYC で本人確認書類をアップロードしてもらい、本人確認をしていますが、提携先さまがその情報に依拠できるしくみです。この API を作る検討をした時に、OpenID の Identity Assurance という規格を使おうと考えていたところ、Authlete さんがもうすでに対応されていました。これを使えばすぐできそうということで、実際に利用したところバリデーション周りで、すごく助かりました。
構築工数の低減
工藤 (Authlete): Authlete を使った部分の作業は、全体の工数はではどれくらいだったでしょうか。
都木 (au じぶん銀行): 実際の開発期間はテスト工程を含めて 6 ヶ月ぐらいでした。2023 年の 7月にリリースしています。API 基盤の更改プロジェクトの中では、委託先の会社さんの方でも Authlete 側に割り当てたメンバーが、10 人ぐらいの中で 1〜2 人だったので、全体で見てもやっぱり 1 割から 2 割くらいだと思います。
ユースケースの拡大
工藤 (Authlete): Authlete の部分はあんまり手間かかってないよ、という話を先ほどからいくつか伺っています。それ以外に、Authlete を使って良かった点はいかがでしょうか。
紙中 (セブン銀行): 2023 年の頭に、CIBA フローを使ったユースケースもできました。新しい使い方を広げられたのは、すごく大きいかなと思います。
穴井 (みんなの銀行): ドラフトですが最近 FAPI 2.0 の認定を取りました。Authlete も FAPI 2.0 に対応しているので、設定の変更だけである程度対応ができたのが大きかったと思います。
機能の分散によるリスク低減
工藤 (Authlete): アーキテクチャー的には、au じぶん銀行さんさんのところだと、MuleSoft と Authlete で機能の分散などで、なにか良かった点はありましたか?
都木 (au じぶん銀行): 万が一ではありますが、先々 API ゲートウェイの基盤を変えねばならない状況になったとしても、改めて新しい基盤から Authlete につなげばいいだけです。やっぱり専門的な知識・ノウハウが必要な機能を SaaS の形でうまく分けられているところは、先々においてもメリットになるのではないかと見ています。
工藤 (Authlete): Authlete はカスタマイズ性の度合が適度だと思うんですよね、わたしから見て。完全に任せるのではなく、完全に作るのでもなく、というところで、うまく分散できることもあると思います。
今後の展望
工藤 (Authlete):
都木 (au じぶん銀行): わたしたちのところでは、参照系 API しかないところに対して、少しずつ更新系 API を作る動きが始まっています。
そのひとつとして、au じぶん銀行アプリという名前の銀行アプリを提供していますが、サーバーとアプリ間の通信を非常にレガシーなインターフェースでやっております。それによって、アプリの開発者も、幅広な知識がないと作れない、という好ましくない状況になっています。
そのため更新系 API も含めて、アプリとの通信全体を API で接続する、そしてその先は作った API を、他のシステム、グループ各社、他社に拡げていきたいな、と考えています。
紙中 (セブン銀行): セブン銀行自身が事業の多角化を図ろうとしています。特にセブン＆アイグループが提供している、グループ共通 ID の７ｉＤをもっとうまく使って、小売と金融を結びつけていこう、ということに取り組んでいます。
そうしていくと、モバイルの連携ですとか、小売のお客さまに金融サービスを提供できるよう、API の提供の幅や場面を広げていく必要があります。そういう意味で、いろいろ活用を検討していきたいなと思います。
穴井 (みんなの銀行): 先ほども話しましたが、FAPI 2.0 の対応があります。認定を取りましたけども、まだ提携先様にはご案内していない状況なので、これから順次、準備ができ次第ご案内していきます。FAPI 2.0 は FAPI 1.0 に比較して、より開発しやすい仕様になっています。FAPI 2.0 を提案することで、より提携先様が導入しやすくなる流れを作っていけたらなと思っています。
あともうひとつ、アメリカやカナダで活動している、FDX という団体があります。金融業界の仕様を統一しようと活動をしているグループです。そちらに当社のメンバーが参加しています。
日本では API の仕様が統一されておらず、提携先様が各銀行に合わせて作っていかなくてはなりません。FDX の統一的な仕様をどうにか日本にも取り入れられないか、調査するチームが立ち上がりました。その活動をやっていけたらなと思っています。
工藤 (Authlete): 我々も FDX に加入して、みんなの銀行さんが中心にやられているタスクフォースにも入れていただいています。また電子決済等代行事業者協会という団体でも、スタディグループで、 FDX の調査などを始めているようなので、多分 2024 年、そのあたりの標準化は動きがあるかなと思います。
ということで、パネルは以上となります。皆様、今日はありがとうございました。
