有価証券決済システムの発注は、発注形態を選び、要件をRFPにまとめ、契約と責任分界を決めてから委託先を比べる流れで進めます。決済は約定から資金の受渡しまでつながっているため、この順に条件をそろえるほど、稼働後の安定運用につながります。
▼全体ガイドの記事
・有価証券決済システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
有価証券決済システムを外注する前に知っておくべき全体像
有価証券決済システムは、約定後に証券を移転し、対価となる資金を受け渡すまでを管理する基幹システムです。発注時は「決済画面を作る」と捉えず、約定から会計、監査証跡、外部との接続までを一つの業務の連鎖として整理します。
DVPとフェイル処理は発注範囲の中心
DVPはDelivery Versus Paymentの略で、証券の引渡しと代金の支払いを相互に条件付け、一方が実行されなければ他方も実行しない仕組みです。この仕組みは、証券を渡したのに代金を受け取れない、または代金を払ったのに証券を受け取れない「取りはぐれ」リスクを避けるための方法です。
日本銀行もDVPをこのように説明しています。出典は、日本銀行「DVPとは何ですか？」、2026年確認です。
フェイルとは、決済日に証券または資金を引き渡せず、受渡しが完了しない状態です。原因には残高不足や資金不足があり、口座情報の誤りや相手方の未処理、通信障害もフェイルの原因になります。このため、RFPには異常時の扱いまで書き、外注先の説明でも、次の扱いを業務シナリオと画面・電文の両方で確かめます。
- 片側成功：証券と代金のどちらか一方だけが成功した場合の処理。
- 通信・再送：通信が切断された場合や、同一指図が再送された場合の扱い。
- フェイル管理：未了ステータスの管理、再送の可否、取消・補償、担当者への通知。
- 照合・記録：日次照合と監査ログの保存。
外部接続と社内システムの責任分界
有価証券決済では、JASDEC、日銀ネット、取引所、清算機関、SWIFTなどと接続する可能性があります。接続方式が専用線か閉域網か、ゲートウェイを自社で持つか外部サービスを使うかによって、初期費用だけでなく運用体制と障害時の連絡網も変わります。
たとえば、発注者が「外部接続はベンダーに任せる」とだけ記載すると、接続申請や試験環境の準備、証明書・鍵管理、相手先との調整が別費用として扱われやすいです。そのため、RFPでは次の範囲と担当を明示し、責任分界表にまとめます。
- 社内機能：約定管理、勘定系、資金繰り、会計、AML・制裁対応、データ分析のうち、新システムに含める範囲。
- 担当者：発注者、元請け、接続専門会社、金融機関側の各担当。
- 役割：電文仕様の確認、障害の一次受け、復旧判断を、それぞれ誰が担うか。
有価証券決済システムの発注形態の選び方
発注形態には、パッケージ、クラウドと個別アプリ、オンプレミス、全面スクラッチがあります。制度に依存する部分と、自社独自の業務の差分は分けて評価します。
パッケージ・ゲートウェイ型の特徴
決済照合、証券残高、DVP、清算、資産管理などに対応するパッケージを採用し、独自業務はAPIや拡張機能で追加する方式です。
制度や電文仕様の変更をベンダーの保守に乗せられるため、全面スクラッチに比べて将来の改修負担を読みやすいです。
証券決済や外部接続を対象とする製品も公開されています。たとえば、東証コンピュータシステムの保振日銀接続パッケージや、SCSKのTradeOneがあります。
一方で、パッケージは標準の業務フローに合わせる必要があり、ライセンス、保守、バージョンアップ、制度変更対応の費用も継続してかかります。このため、RFPでは次の点を質問し、将来の製品終了やベンダー交代の際にデータを取り出せるかも確かめます。
- 提案確認：対象商品の範囲、接続先、導入実績、個別改修の扱い。
- 機能区分：標準機能、設定で対応する機能、個別開発になる機能に分けます。
クラウドとオンプレミスの比較
クラウドはサーバーを購入する初期負担を抑えやすく、監視やバックアップの標準サービスも使いやすいです。ただし、有価証券決済では次の設計が追加になるため、「クラウドだから安い」とは限りません。
- 接続と鍵：専用線・閉域接続、暗号鍵、アクセス権限。
- 記録と復旧：ログ保管、バックアップ、冗長化、障害時の切替。
金融機関や基幹インフラ事業者は、クラウド事業者を含めた第三者リスク管理と委託先管理を確認します。
オンプレミスは設備やネットワークを自社の方針に合わせやすい反面、機器更新、データセンター、災害対策、24時間監視の費用がかかります。
低遅延や既存設備との接続を最優先にするなら、オンプレミスは有力な選択肢になります。その場合も、5年程度の総保有コスト、障害時の代替拠点、保守部品の供給期間を、クラウドと同じ条件で比べます。
一括発注と分割発注の責任分界
元請けのSIerに要件定義から運用まで一括で委託するか、分けて発注するかを比べます。
- 一括発注：窓口が一本化され、障害時の調整が比較的しやすくなります。
- 一括発注の注意：接続専門会社やパッケージベンダーの知見が元請けに不足すると、再委託先への依存が深くなります。
- 分割発注：専門性を直接買えますが、全体アーキテクチャ、データ整合性、試験計画、障害時の指揮命令を発注者が担います。
発注形態は見積金額だけでなく、要件定義の成果物を誰が作るか、外部接続の試験窓口を誰が持つか、障害原因が複数社にまたがったとき誰が切り分けるかで判断します。
発注者に金融業務やプロジェクト管理の人材が少ないときは、第三者のPMOや上流支援を先に委託し、その後で開発会社を競争させる方法も有効です。
RFPと要件整理で発注先へ伝える内容
RFPは、達成したい業務成果、対象範囲、制約条件、評価方法をそろえて提案を求める文書です。作ってほしい機能を並べた依頼書とは、性格が違います。
候補会社が同じ前提で見積もれるよう、資料は一式にまとめて渡します。現行業務と将来の取引量、外部接続の条件を示し、非機能、移行、運用、契約条件も含めます。
業務要件の具体化（商品・参加者・決済方式）
「決済を自動化する」とだけ書くと、成功の条件が曖昧になります。照合や更新の条件まで具体化しておきます。
- 商品・参加者：株式、国債、社債、投資信託と自社、顧客、証券会社、信託銀行、清算機関。
- 決済条件：RTGSかネット決済か、DVPの型、決済日、受付開始・締切時刻、休日、時差。
- 例外・統制：資金繰り、担保、フェイル、取消、補償、夜間バッチ、手動介入、承認、権限分離、監査報告。
- 自動処理：約定照合時間、不一致通知先、重複検知キー、更新する残高と会計仕訳。
- 処理量：日次平均、締切前ピーク、同時実行数、障害復旧後の再処理量。
非機能要件の数値と試験方法
金融システムの安全対策では、サイバー攻撃の予防だけでなく、検知、復旧、委託先管理、経営層の関与まで問われます。RFPに「安全にする」とだけ書くと、各社が何をどこまで見積もったのか比べにくくなります。
基準の版も、会社ごとに前提が食い違う原因になります。FISCは2025年3月に安全対策基準・解説書の第13版を公表し、現在は第14版も案内されています（出典: FISC「FISCガイドラインPDF版」、2026年確認）。そのため、適用する版と社内基準を発注前に明示します。
非機能要件は、次の項目を数値で指定します。
- 稼働・性能：稼働時間、可用性、RTO、RPO、応答時間、ピーク性能。
- 保全：ログ保存期間、バックアップ頻度、切替時間、保守時間。
- 障害対応：検知、一次連絡、暫定復旧、原因報告の目標時間。
- 接続停止：手動切替、保留、再送の方式と、総合試験での判定。
数値と試験方法を決めないと、「高可用性」の見積前提が会社ごとに異なります。
RFPに含める成果物・提案書・見積の提出条件
提案書に加えて、前提、対象外、実施方針、発注者作業、工程別の見積を、同じ条件で求めます。
- 提出資料：前提・対象外一覧、WBS、体制、日程、リスク一覧。
- 実施方針：試験・移行方針、運用設計、保守範囲、ライセンス明細。
- 見積内訳：要件定義、設計、開発、接続、各種試験、移行、教育、稼働後支援。
- 発注者作業：データ提供、業務確認、申請、試験調整、受入テスト、教育、休日立会い。
見積は、工程ごとに人員、期間、前提、別途費用を記載する形式にそろえます。また、発注者側の作業も、工数と担当部署を決めておきます。
不明点は質問票で確認し、未回答の項目はリスクとして記載するよう依頼します。そうすると、低い金額だけを出す提案を見分けやすくなります。
契約形態の使い分け（請負・準委任・保守）
要件が固まっていない上流工程と、成果物を定めやすい開発工程とで、契約を分ける方法があります。契約名だけでなく、範囲と完成の定義も確かめます。
検収、変更管理、損害賠償、再委託の扱いは契約で定めます。さらに、秘密保持、監査、データ帰属、終了時の移行も、同じ契約に盛り込みます。
要件定義は準委任、完成物は請負
上流工程は準委任、完成条件を合意しやすい工程は請負が候補になります。
- 準委任：現状調査、構想、要件定義、技術検証、PMO支援。
- 準委任の成果物：議事録、業務一覧、要件定義書、RFP、PoC結果。
- 請負：設計、開発、テスト、移行。検収を画面動作の確認だけにはしません。
- 検収基準：正常系、再送、タイムアウト、フェイル、片側成功、復旧、性能、権限、監査ログ。
- 変更条項：制度や外部仕様が変わったときの、費用と納期の協議。
準委任は稼働時間や専門人材の提供を対価とする契約ですが、成果への責任がないわけではありません。作業内容、報告義務、善管注意義務、課題管理のルールを明確にします。
保守契約のSLAと制度変更対応
SLAと保守の範囲を決めておくと、障害時に必要な体制や将来の費用を見通しやすくなります。
- SLA項目：問い合わせ対応、障害の重要度、受付時間、一次回答、暫定復旧、恒久対応、原因報告、月次報告。
- 重要度の区分：決済の締切時間に影響する障害と、翌営業日までに直せる軽微な不具合。
- 連絡体制：休日・夜間の連絡先、代替担当者、重大障害時の経営層へのエスカレーション。
- 保守の対象：制度改正、電文変更、接続試験、脆弱性対応、OS・ミドルウェアのサポート終了を、月額に含むかどうか。
制度対応をすべて別料金にすると、数年後の予算が読めなくなります。一方で、無制限の改修を保守に含めると、ベンダーが必要な体制を確保できないため、対象範囲と上限を設定します。
再委託・海外拠点・データ管理の契約上の扱い
金融システムでは、元請け会社だけを審査しても、開発や監視、クラウド運用を別の会社が担うことがあります。そのため、再委託も契約で管理します。
- 委託先情報：再委託先の会社名、所在地、担当工程、アクセスできるデータ。
- 情報管理：開発端末、持ち出し制御、脆弱性管理、事故時の報告、再委託の承認条件、監査権限を、契約に盛り込みます。
- 海外拠点：データの保管場所、越境移転、現地法、政府アクセスのリスク。
経済安全保障推進法の基幹インフラ制度では、指定された事業者が特定重要設備の導入や重要維持管理を委託する際、事前届出と審査が必要になる場合があります。
なお、金融庁は銀行業、第一種金融商品取引業、信託業、資金清算業、振替業などを所管する事業として案内し、導入計画の事前相談も受け付けています（出典: 金融庁「基幹インフラ制度における手続きについて」、2025年更新、2026年確認）。該当性の判断を発注後に始めると納期に影響するため、RFPを配布する前に法務・リスク管理部門と確かめます。
有価証券決済システムの費用相場
公開価格は限られるため、ここに挙げる金額は、対象範囲と接続条件から推定したものです。2025〜2026年時点の目安では、現状調査・構想・要件定義が500万円〜2,000万円です。
ゲートウェイやパッケージ連携は3,000万円〜1.5億円、証券バックオフィス基盤の刷新は1.5億円〜5億円です。さらに、複数商品・複数拠点の大規模刷新は5億円〜数十億円以上です。いずれも、金融ミッションクリティカルシステムに必要な設計・接続・試験・移行工数から算出した推定レンジです。
対象範囲ごとの費用比較
費用は対象範囲ごとに異なるため、金額と含まれる作業を対応させて比べます。
- 構想・要件定義：500万円〜2,000万円。現行調査、業務フロー、接続方式、非機能、RFP。
- ゲートウェイ連携：3,000万円〜1.5億円。電文変換、照合、社内連携、接続試験、教育。
- 基盤刷新：1.5億円〜5億円。証券・資金・残高・会計、移行、災害対策、運用設計。
- 大規模刷新：複数商品・拠点、24時間運用、段階移行、旧新並行、災害時切替、制度変更対応が重なり、数十億円以上の可能性。
相場のレンジをそのまま予算にはせず、まず自社の条件を仮置きします。対象商品、参加者数、ピーク件数、接続先を決めたうえで、可用性、RTO・RPO、移行データ量もそろえます。同じ条件で概算を依頼します。
見積の内訳と漏れやすい費用
見積を比べるときは、次の工程比率を仮の確認軸にして、抜けやすい費用と総額も確かめます。
- 工程比率：要件定義・業務設計15〜25%、アプリ開発・連携25〜40%。
- 基盤・試験：インフラ・ネットワーク・セキュリティ10〜20%、外部接続・総合試験15〜30%。
- 移行等：データ移行、教育、稼働後支援10〜20%。
- 漏れやすい費用：専用線、鍵、接続申請・試験、データ整備、リハーサル、切戻し、休日立会い、監査、更新、制度・脆弱性対応。
- 総額：保守、クラウド、ライセンス、監視、バックアップ、災害対策を含む5年分。
比率は案件ごとの正式な標準ではありませんが、どの工程が極端に少ないかを見つけるのに役立ちます。
デジタル証券やデジタル通貨への拡張を想定する場合でも、将来の機能を最初から全面実装する必要はありません。たとえば、2025年3月には、BOOSTRYや三井住友銀行、野村ホールディングスなどが、デジタル債の売買情報と銀行送金情報を照合するDVP決済の概念実証を公表しました。出典は、野村ホールディングス「国内初の決済スキームによるデジタル債の発行」、2025年です。
RFPでは、将来のAPI・台帳・決済手段の追加余地を要求し、今期の必須費用と将来拡張費用を分けて見積もります。
委託先の選定と見積比較で確認する項目
委託先は、金融機関向けの実績があるかだけでなく、どの業務と接続を担当したかで比べます。確認するのは会社の知名度よりも、自社のリスクを減らせる証拠です。
候補には、証券・資金・会計を一体で扱う大規模SIer、保振・日銀接続に強い専門会社、証券バックオフィスのパッケージベンダーがあります。また、クラウド・セキュリティ会社も含めて組み合わせる選択肢もあります。
実績の確認（接続・障害対応）
金融実績は件数よりも、どの業務と接続を担当し、障害にどう対応したかで見ます。
- 実績の範囲：商品、決済方式、JASDEC・日銀ネット接続、1日あたりの処理量、稼働年数。
- 対応実績：移行、障害復旧、制度変更への対応。
- 参考資料：匿名の紹介先、同じ構成のデモ、障害報告書のサンプル。
- PoC：正常なDVPを一度動かすだけでなく、重複指図、電文の順序逆転、片側停止、再送、フェイル、取消、復旧後の照合、権限外操作まで試せるかを見ます。
ベンダー側から異常系を提案できるかどうかも、金融業務への理解を見極める材料になります。
同じシートでの見積比較（金額・前提・リスク）
各社の金額は単純に足し引きせず、次の項目を同じ比較シートに転記します。未確定の項目は空欄にせず、仮定、除外、変動条件として残します。
- 開発範囲：要件定義の範囲、開発対象、外部接続数。
- 試験・運用：試験環境・ケース、移行件数、教育、運用引継ぎ、保守期間。
- その他費用：ライセンス、クラウド利用料、発注者作業、再委託費、税の扱い。
- 配点例：業務・接続実績30%、提案の適合性20%、試験・移行・運用20%、セキュリティ・委託先管理15%、費用・契約15%。
配点は価格以外も含めて事前に決め、自社の事情に合わせて変えます。最安値を自動採用せず、費用が安い理由と追加費用の可能性を数字で示せる会社を選びます。
最終面談の同席者と確認事項
営業担当だけでなく、実務責任者とも面談し、担当体制や引継ぎ条件を確かめます。
- 同席者：要件定義、設計、テスト、運用の各責任者。
- 質問：締切・外部仕様変更、障害連絡、移行切戻しへの対応。
- 要員：契約後の担当継続、責任者の稼働率、代替要員。
- 引継ぎ：ソース、設計書、試験証跡、データ辞書、手順、監視、鍵・証明書。
また、移行支援の費用と期間も決めておきます。ベンダーの交代を想定しておくことは、相手を疑うことではなく、システムの継続性を保つための通常のリスク管理です。
有価証券決済システムの発注・外注でよくある質問
発注前によくある疑問を取り上げます。費用や契約条件は、対象商品、接続先、体制、セキュリティ基準によって変わります。
有価証券決済システムの外注費用は数千万円で収まりますか？
構想・要件定義や限定的な連携なら、数千万円規模になる場合があります。証券・資金・残高・会計を含む刷新は1.5億円〜5億円、大規模刷新は5億円以上になる可能性があります。
金額は公開された価格ではなく推定です。そのため、対象商品、接続先、処理量、可用性、移行範囲をそろえて見積もりを取ります。
RFPを作れない状態でも発注先を探せますか？
RFPが未完成でも発注先を探せます。いきなり開発見積を依頼するより、現状調査・構想・要件定義を準委任で委託する段階を設ける方法が安全です。
現行業務、対象範囲、接続、非機能、移行、運用を整理してRFPにします。その後に複数社を比べると、追加費用や認識違いを減らせます。
有価証券決済システムはクラウドへ外注できますか？
有価証券決済システムは、クラウドへ外注できる可能性があります。採用時は、金融庁とFISCの基準、社内基準を確認し、外部接続、鍵、ログ、冗長化、障害時の切替、第三者リスクを確かめます。
事業者、発注者、SIerの担当範囲は、責任共有モデルで分けておきます。また、監査資料や障害報告を取得できることも、契約条件に含めます。
基幹インフラ制度の確認はいつ行えばよいですか？
候補会社を絞る前、少なくともRFPを配布する前には、法務、リスク管理、情報セキュリティへ相談します。
指定事業者や特定重要設備に該当する場合、導入や重要維持管理の委託には事前届出と審査が関係します。そのため、選定、契約、接続試験の日程に反映します。
該当しない場合でも、供給者や再委託先のリスクを早い段階で評価します。
まとめ
発注では、DVPやフェイル、再送、取消、外部接続など、異常時の業務まで含めて範囲を定めます。そのうえで、パッケージ、クラウド、オンプレミス、スクラッチを比べます。
必要に応じて、上流の要件定義と開発を分けて発注します。RFPには、商品・参加者・決済方式、処理量、非機能を記載します。テストや移行、運用に加えて、再委託、セキュリティ、制度変更対応も盛り込みます。
費用は、要件定義500万円〜2,000万円、ゲートウェイ・パッケージ連携3,000万円〜1.5億円、基盤刷新1.5億円〜5億円などの推定を出発点にします。各社の見積は同じ前提で並べ、接続試験、災害対策、保守、ライセンスを含む5年総額で判断します。
委託先は、証券・資金をまたぐ整合性を設計でき、異常系を試験し、障害と制度変更に継続して対応できるかで選びます。知名度や最安値よりも、この点を重く見ます。
発注前に責任分界と出口条件まで合意できれば、稼働後の追加費用やベンダー依存を抑えながら、安定した決済基盤を築きやすくなります。
▼全体ガイドの記事
・有価証券決済システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。