金融プラットフォーム開発の面白さ

Welcome Fintech #6 夏の大トーク大会 ! 金融プラットフォーム開発の 面白さ Finatext ｜ Kobayashi Takuma (@takuma5884rbb) © 2026 Finatext Holdings Ltd.

ABOUT ME 小林 拓磨 Kobayashi Takuma @takuma5884rbb CAREER ROLE エンジニア 4 年目 フルサイクルエンジニア RECRUITING HOB BY 新卒採用リーダー 料理とランニング © 2026 Finatext Holdings Ltd. 2

ABOUT F I N AT E X T Finatext は、金融サービスのあり方への問題意識から創業しました。 現状の課題 解決に必要なこと F I N AT E X T の ア プ ロ ー チ 金融の便益が、 一部の人にしか届いていない 全システムの質の向上 × 業務・サービスの変革 金融機関とともに変革する 「パートナー」 本来、金融サービスは人々の生活をもっと豊 かにするポテンシャルを持つはず。 基幹からフロントまで全てのシステムと、業 務・サービスの両方を変えることが不可欠。 AI 中心のテクノロジーで基幹システムとデー タ基盤をアップデートし、業務とサービスを 連続的に変革。 GROUP MISSION GROUP VISION 旧来の複雑さにとらわれず、ゼロからサービスとして組み直す。 誰もが自然に使えて、安心して頼れる金融を、あたりまえに。 金融を“サービス”として再発明する 金融がもっと暮らしに寄り添う世の中にする © 2026 Finatext Holdings Ltd. 3

IMAGE VS REALITY 金融システム開発の「イメージ」と、 Finatext の「実態」。 世間のイメージ Finatext の実態 ✕ COBOL が動くレガシーな巨大システム ○ Go 、 AWS 、 gRPC ✕ ウォーターフォールと分厚い仕様書 ○ 細かいデプロイ粒度で、小さく頻繁にリリース ✕ 「触るのが怖い」基幹システム ○ 万が一に備えたロールバック体制で、 細かくリスクコントロール ✕ ベンダー任せ開発・運用 ○ 業務設計や BPO まで一気通貫で伴走 © 2026 Finatext Holdings Ltd. 4

SECURITIES BaaS 証券サービスに共通して必要な機能を、 API として提供しています。 証券サービス A 証券サービス B 証券サービス C API API API S E C U R I T I E S B U S I N E SS P L AT F O RM 証券ビジネスプラットフォーム「 BaaS 」 証券口座の管理 残高の管理 税計算 ほか共通機能 口座開設・審査・維持 保有資産・取得単価 特定口座・ NISA ・損益通算 注文・約定、入出金 など どの証券サービスにも必要な機能を基盤が共通提供するから、パートナーはサービス独自の体験づくりに集中できる。 © 2026 Finatext Holdings Ltd. 5

SECURITIES BaaS #1 「残高」を因数分解すると、ズレの連鎖が見えてきます。 残高 コアデータ 取得単価 購入価格＋手数料 損益 税金 売買の価格差 法律に従い計算 トータルリターン 分配金まで考慮 さらに 外国株なら「為替」計算。 NISA の非課税枠は時価ではなく「簿価」で管理される。 ズレは連鎖する 約定で金額がズレる 取得単価がズレる © 2026 Finatext Holdings Ltd. 損益がズレる 税金までズレる 6

SECURITIES BaaS #2 単なるマルチテナントではない、「二重マルチテナント」という構造。 約 50 マイクロサービス 33 プロダクト 6 チーム で内製 証券ビジネスプラットフォーム BaaS 証券会社 A プロダクト 1 証券会社 B プロダクト 2 プロダクト 3 プロダクト 4 テナントごとに異なる外部接続先や DB は、アプリケーションコードから透過的に切り替えて、ビジネスロジックの共通化を守る。 © 2026 Finatext Holdings Ltd. 7

INSURANCE & CREDIT 保険とクレジットにも、全く違う顔をした手強さがあります。 INSURANCE Inspire CREDIT Crest 保険ビジネスプラットフォーム クレジットプラットフォーム 商品は実体ではなく「契約のテンプレート」 借入と返済を繰り返す循環型ライフサイクル 状態は上書きせず、履歴を積み上げる 理論で議論し、モジュラーモノリスを採用 EC の SKU ・在庫とは主語が違う。データの主体はあくまで「契約」。 事故のあとに特約を解約されても、事故時点の契約状態を再現して査 定する。 残高・日割り利息の計算がどんどん複雑になる。 法規制で縛られた状態遷移は、 Go のジェネリクスでコンパイル時に 検証。 今日はダイジェストのみ。どちらも、それだけで一本の発表が組めるほど奥深い領域。 © 2026 Finatext Holdings Ltd. 8

RIGHT ABSTRACTION #1 一つの機能が、複数のサービスから、絶妙に違うユースケースで使われます。 プラットフォームは単一プロダクトではなく、運用とパートナーのビジネス展開までを見据えて設計する。 サービス A のユースケース ある機能 例 : 口座開設、入出金、 サービス B のユースケース 通知、認証 … 絶妙な違い 全く異なるわけでも、完全に 同じわけでもない。 サービス C のユースケース 設計には両極の失敗がある ✕ 具体的すぎる 特定ユースケースに寄り、再利用性が低い。類似 実装を再生産してしまう。 ○ 使いやすい抽象度 複数サービスで使い回せて、システムの汎用性が 最も高い状態。 © 2026 Finatext Holdings Ltd. ✕ 抽象的すぎる 利用側が足りないロジックを個別実装。使わない 場合と同等の労力に。 9

RIGHT ABSTRACTION #2 「 Slack に投稿する」ではなく、「外部サービスに投稿する」と設計します。 例 : 「ログを Slack に投稿する」機能を作ったあとで、 Discord にも投稿したくなったら？ ✕ Slack API を直接呼ぶ ○ 「外部サービスにログを投稿する」 Slack ログ発生箇所 Slack API ログ発生箇所 抽象 IF Discord Slack のインターフェースに依存した実装に。 内部実装を用意して呼び分けるだけ。 Discord 対応は大改修になる。 汎用性が最も高く、横展開が容易。 「適切な抽象度」を探り当て、開発を続けながら維持するのは、言葉以上に難しい © 2026 Finatext Holdings Ltd. 10

P L AT F O R M LEVERAGE 基盤側のひとつの実装が、証券業界初のパスキー認証になりました。 Enabling Team 発・社内 OSS 2025 年 8 月・スマートプラス clearance 証券業界初のパスキー認証 Ory Hydra + Amazon Cognito + 独自マルチテナント層の 第一弾は三菱 UFJ アセットマネジメント「 mattoco+ 」。 認証認可基盤。パスキー（ WebAuthn ）対応を基盤側に組み 以降、パートナー企業のサービスへ順次展開。 込み。 パートナーは追加費用なしで、フィッシング耐性のある次世代認証を利用可能に 出典 : スマートプラス プレスリリース（ 2025 年 8 月 6 日） https://smartplus-sec.com/news/press/20250806 © 2026 Finatext Holdings Ltd. 11

• https://smartplus-sec.com/news/press/20250806

RECAP 金融プラットフォーム開発の、面白さの正体。 01 02 「使いやすい抽象度」の探求 03 プラットフォームのレバレッジ 法規制、監査、お金の正確性。破れないか 複数サービス・絶妙に違うユースケース。 基盤に載せた工夫は、全パートナー・その らこそ、設計の前提が明確になる。 答えのない設計判断に向き合い続ける。 先の全エンドユーザーに一気に効く。 絶対に破れない制約 制約が厳しいほど、設計はクリエイティブになる。 © 2026 Finatext Holdings Ltd. 12

BOOK & INDEX 今日話せなかった内容は、技術同人誌でお楽しみください。 INDEX — 今日話せなかった内容 BOOK Finatext グループ 技術同人誌 クラウドネイティブ編 横断的技術編 証券 BaaS 保険・クレジット 電子版はこちら techbookfest.org データ・ AI © 2026 Finatext Holdings Ltd. Platform Engineering / Two Person Integrity などの守りの仕 組み Enabling Team / 業務 AI アシスタント Alfred / AI 営業アシスト FAA 複雑な法規制対応。 FIX ・ ITCH ・専用線などの外部システム接続 約款のデータモデル化 / BiTemporal Data Model / Type-safe FSM 100TB 規模のオルタナティブデータ基盤と、データ ×AI の事業展 開 13