FATCA対応システム開発の進め方/やり方/流れや方法/手法/工程/手順

FATCA対応システムの開発は、制度確認と現状調査から始めます。続けて、データ設計と方式選定を行い、実装・テストと本番移行へ進めると、手戻りを抑えられます。制度と業務条件を先にそろえてから実装に入るのが、その前提です。

全体像は、FATCA対応システム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・FATCA対応システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

FATCA対応システムの全体像

FATCAは、米国の外国口座税務コンプライアンス法に基づく報告制度で、外国金融機関などが米国人の口座情報を報告します。日本では、国税庁から照会を受けた金融機関が、e-TaxのFATCAコーナーで情報を送信する場合があります。なお、米国側には、IRSのIDESという電子交換窓口があります。

FATCA対応システムは、制度上の判断と報告作業を、社内の顧客・口座データに結び付ける業務システムです。

顧客判定から報告までをつなぐ主要機能

顧客判定から報告までには、情報の収集と分類、書類の管理が欠かせません。また、データ検証やXML生成、監査記録も、機能として備える必要があります。

• 情報と書類の管理：顧客・口座・法人情報、自己証明書、W-8・W-9関連書類を扱います。
• 判定と報告：米国 indiciaの検知、顧客分類、報告対象口座の抽出、XML生成までを担います。
• 統制と記録：データ品質の検証結果、提出履歴、監査証跡、例外対応の記録です。

情報は、既存の勘定系やCRMのほか、投資信託や証券、保険のシステムから取り込みます。さらに、文書管理システムも取り込み元になります。一方で、画面を作るより、データ項目の意味と責任部署をそろえる作業のほうが大きくなりやすいです。

米国出生地や米国電話番号、送金指図などを検知した場合は、追加確認のケースとして管理します。ただし、米国住所があるだけで報告対象と確定するわけではありません。

システムでは、自己証明書の未提出や期限切れ、記載内容とマスター情報の不一致も、担当者への割り当てから差戻し、承認、再確認まで追跡します。

FATCA・CRS・AMLの目的の分け方

FATCA、CRS、AMLはいずれも顧客情報を使いますが、目的と報告先がそれぞれ異なります。そのため、設計では制度ごとの違いを分けて扱います。

• FATCA：米国人等に関する国際税務上の情報交換が目的です。
• CRS：各国の税務上の居住者情報を自動で交換します。
• AML：マネー・ローンダリングやテロ資金供与のリスクを管理します。

判定ルールや報告先、保存期間、利用権限を制度間で共通化すると、誤った二次利用や責任分界の不明確化につながります。

顧客・口座マスター、本人確認書類、住所変更履歴、取引情報は、共通で利用できる場合があります。そのうえで、FATCA専用の判定・報告機能を既存のAML・KYC基盤に接続する構成が現実的です。

初期の段階で、共有するデータと制度ごとに分けるデータを決めておくと、重複入力や過剰なアクセス権を防げます。

FATCA対応システムの進め方・開発工程

開発は、制度確認と現状調査から始め、データ設計と方式選定、実装とテストを経て、本番移行、年次運用へと進みます。

画面やXMLから作り始めると、報告範囲やデータの責任部署が変わり、手戻りが増えます。そのため、まず業務イベントと提出要件を固め、必要なデータと機能を逆算します。

1. 制度・提出先・報告範囲の要件定義

要件定義では、報告の対象となる法人・商品・口座・顧客区分を明確にします。そのうえで、報告対象年や提出先、IGAのモデル、初回提出・訂正・取消の扱いを決めます。

金融機関の分類や対象範囲は、業態と契約関係によって変わります。そのため、情シスだけで決めず、税務・コンプライアンス・業務部門と合意します。

国税庁の2026年1月資料では、FATCAスキーマのversion属性を「2.0」とする扱いです。

FATCAXML-v2.0.1が公表済みであっても、「2.0.1」と記載しないよう案内されています（出典: 国税庁「FATCAスキーマ記載に係る留意事項」、2026年）。

• 業務と制度の前提：対象業務一覧、制度・IGAの前提、報告項目一覧、業務用語集、責任分界表を用意します。
• 責任分界：米国 indiciaの確認者、税務分類の承認者、ファイル提出の担当者の一覧です。
• 自動化の範囲：システムに任せる判断と、担当者が確認する業務の境目です。

2. 顧客データの棚卸しとsource-to-target mapping

報告に必要な情報が、どのシステムにあるかを洗い出します。対象は、顧客・口座・法人の情報から、残高、所得、税務情報、証明書、GIINまでです。

• 勘定系：口座番号と残高を確認します。
• CRM：住所と連絡先の確認先です。
• 文書・法人管理：自己証明書と組織情報が該当します。

情報は複数の場所に分散しているのが一般的です。そのため、mappingには元項目名と変換ルールを書き、必須・任意、文字種、コード体系、更新頻度、欠損時の扱い、責任者も記録します。

変換ルールとして、住所の国コードを日本語表記からISO形式にする、氏名の全角・半角を整える、TIN形式を検証するといった処理を定義します。

未確定の項目を後回しにすると、テスト直前になって欠損が見つかります。さらに、例外データの件数も早い段階で測定しておきます。

3. ルール実装からテスト・並行稼働まで

実装やテスト、移行では、機能が動くかどうかだけでなく、判定根拠や提出後の訂正を追えるかどうかも受入条件に含めます。

• 実装：データ取込、分類、証明書管理、例外ワークフロー、XML、提出履歴、権限、監査ログの各機能です。
• ルール管理：ルールの版、適用開始日、根拠資料、承認者を登録し、過去の判定を再現できるようにします。
• テスト：単体、連携、スキーマ、業務シナリオ、権限・セキュリティ、性能、障害復旧の各観点で確認します。

例外シナリオとして、indicia検知後に有効な証明書がある場合や、住所変更後の再確認、初回提出後の訂正、複数口座の一部取消を盛り込みます。

受入条件には、XMLが生成できることに加えて、元データや判定根拠、承認者、提出結果、再提出内容を追跡できることを含めます。

本番移行では、過去データの補正と初回データの取り込みに加えて、利用者教育、手作業時の代替手順、並行稼働期間を決めます。

参考例として、Wiproは大手グローバル銀行向けに10系統のデータをmappingしました。

Wiproは、4か国へ12か月でFATCA remediation solutionを展開した事例も公開しています（出典: Wipro公開事例）。

対象国やデータソースが増えるほど、期間を左右するのは開発だけでなく、データ整備と業務調整です。

年次運用では、規制やスキーマの更新、未提出案件と期限切れ書類の対応、差戻しと再提出、監査依頼への回答を繰り返します。

国税庁のFATCAコーナーでは、2026年1月5日に事前準備セットアップが更新されています。制度や提出環境の変更も、運用計画に含めておきます（出典: 国税庁「FATCAコーナーについて」、2026年）。

FATCA対応システムの費用相場とコストの内訳

日本向けのFATCA対応システム開発費は公開情報が少ないため、ここに示すのは2026年時点の概算です。予算を立てる際の起点として使い、要件定義の後に個別の見積もりで確認します。

金額は、対象口座数やデータソース数、連携方式、過去データの品質、オンプレミスの要否、他制度を含める範囲によって変わります。

規模別の初期開発費（800万円から2億円超）

規模別の予算は、対象法人の数やデータソースの数、統合範囲によって変わります。あわせて、導入期間も比較します。

• 小規模・限定導入：1法人、1〜2データソースが対象で、800万〜2,000万円程度です。
• 中規模・業務統合：複数商品、3〜10データソースが対象で、2,000万〜6,000万円程度です。
• 大規模・グループ展開：複数法人と海外拠点が対象で、FATCA・CRS・AML連携を含めると、6,000万〜2億円超となる可能性があります。

小規模では、証明書管理、基本分類、XML生成・検証、手動提出を想定します。既存データが整っていて、画面で例外を確認できる場合は、4〜8か月程度で導入を検討できます。

中規模では、案件ワークフローや訂正、監査証跡、APIやETL連携を含み、期間は8〜14か月程度です。さらに、データ補正や複数部署の承認が入ると、データ移行と業務設計の比重が増します。

大規模では、高可用性やデータレイク、権限分離、運用監視などを含み、期間は12〜24か月以上です。

Wiproの4か国・12か月の事例は、大規模案件の期間を考える際の参考になります。ただし、国内の単一法人にそのまま当てはまる数字ではありません。

ライセンス費・移行費・保守費の分け方

見積もりは、開発工程、製品利用料、移行、保守に分けて、初期費と継続費の範囲を確認します。

• 開発工程：要件定義、設計、画面・ワークフロー、連携、XML、テスト、移行、審査、教育の範囲を確認します。
• 製品利用料：ライセンス・利用料、初期設定、追加ユーザー、データ量、接続先、規制コンテンツの更新が対象です。
• 運用費：SaaS利用料、クラウド基盤、規制ルール更新、監視、問い合わせ、年次レビュー、脆弱性対応の費用です。

比較サイトでは、CRS/FATCA Oneの開始価格が年間1,500米ドルと掲載されています（出典: Software Advice、2026年）。

CRS/FATCA Oneの開始価格は、小規模向けのエントリー価格で、日本語の税務支援や国税庁向けの設定、連携、移行、エンタープライズSLAまで含むとは限りません。

円換算の数字を比べる前に、必要な業務範囲をそろえておきます。ランニング費は、初期開発費の15〜25％、または年間300万〜3,000万円程度を仮置きします。

規制改定の反映が保守の範囲内か別料金かによって、数年単位の総額が変わります。そのため、契約期間や解約時のデータ返却、バックアップ削除、サポート時間も確認します。

FATCA対応システムの見積もりの取り方

見積もり条件には、対象データ、処理頻度、承認者、提出方式を含めます。RFPに「FATCA対応」とだけ書くと、各社の想定する範囲が異なり、価格と納品物を比べられません。

発注側は、条件を先に整理し、同じ資料を複数社に渡すと比較しやすくなります。

RFPの対象範囲・データ・提出方式の書き方

RFPには、現在の対象範囲と将来のデータ量、提出時の作業分担を記します。

• 対象・データ：法人・口座数、商品、対象国、既存システム、データソース数を記載します。
• 処理と例外：日次・月次・年次の処理頻度、証明書の種類と保管場所、判定ルール、訂正・取消の扱いです。
• 提出と拡張：初回・再提出、手作業、3年後やグループ追加後のデータ量です。

提出先は、国税庁のe-TaxかIRSのIDESかを指定しておきます。そのうえで、生成物がFATCA XMLだけか、署名・暗号化・メタデータを含む送信パッケージかも明確にします。

IRSのIDESは、FATCAデータを標準XMLで送信できます。HTTPSに加えて、SFTPによる一括転送にも対応しています（出典: IRS「International Data Exchange Service」、2026年確認）。

パッケージ・SaaS・スクラッチの比較の観点

方式は初期費用だけでなく、制度変更への追随や統合の深さ、運用責任まで含めて比べます。

• パッケージ：分類、検証、XML、監査履歴を早い段階でそろえやすい方式です。
• SaaS：初期投資と運用負荷を抑えやすい一方で、保管地域や鍵管理などの審査が必要です。
• スクラッチ：既存基盤と統合しやすい反面、スキーマや制度変更への追随を継続して担います。

SaaSでは、テナント分離、サブプロセッサ、障害復旧、契約終了時のデータ返却も審査します。

ハイブリッド方式では、分類・ワークフローを既存基盤に、ルール・XMLを専門製品に、提出履歴・監査ログを自社で管理する構成も候補になります。

製品ベンダーには、日本のe-Tax対応やFATCAXML-v2.0の版の管理、訂正・取消への対応、国内の支援体制を確認します。

SI会社には、source-to-target mappingや移行、税務部門との調整、テスト設計、運用引継ぎの実績を確認します。

監査証跡・セキュリティ・責任分界の受入条件

受入条件では、機微情報を守る統制と、判定から提出までを追跡できること、関係者の責任の範囲を定めます。

• アクセスと保護：最小権限、MFA、職務分離、通信と保存時の暗号化、秘密鍵管理を定めます。
• 運用と復旧：改ざん耐性ログ、バックアップ、脆弱性管理、災害復旧、委託先監査を含めます。
• 監査証跡：元データと変換後データ、ルール版、担当者、承認者、変更前後、提出ID、通知、再提出理由を追跡します。

FATCA情報には、氏名や住所、出生地、納税者番号、口座残高などが含まれます。そのため、保護策は金融機関の委託先管理と合わせて定めます。

FISCの『安全対策基準・解説書』第13版は、2025年3月に公表されました。

第13版では、金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」を踏まえて、項目の新設や見直しが行われています（出典: FISC「安全対策基準・解説書 第13版」、2025年）。

国税庁は、MessageRefIdとDocRefIdに、送付ごとに未使用の新規IDを付けるよう案内しています（出典: 国税庁「FATCAスキーマ記載に係る留意事項」、2026年）。

IDの採番履歴を保存しない設計は、訂正や監査の際に問題になりやすいです。

契約では、税務専門家、業務部門、情シス、ベンダーの責任を分けておきます。そのうえで、規制改定を検知する担当者や、何営業日以内に影響評価するか、改修費を誰が負担するかも決めておきます。

責任分界が曖昧な固定価格契約は、追加費用や納期遅延の原因になります。

よくある質問（FAQ）

導入では、既存のAML基盤を活用できるか、SaaSを使えるか、XML生成をどこまで担うかがよく問われます。答えは、対象範囲やデータ品質、提出方式、監査要件によって変わります。

FATCA対応システムは小規模な金融機関にも必要ですか？

報告業務があり、顧客・口座情報の確認や提出を続ける場合は、規模を問わず仕組み化を検討できます。

最初から大規模な基盤を作る必要はありません。1法人・1〜2データソースで証明書管理や分類、XML検証、提出履歴を導入してから、対象範囲に応じて連携を増やす方法もあります。

既存のAML・KYCシステムにFATCA機能を追加できますか？

既存のシステムに追加できる場合があります。顧客マスターや本人確認、住所・出生地、書類、案件ワークフローは、共有して使えます。

FATCA専用の分類や報告対象の抽出、XML、提出履歴を追加する構成が考えられます。ただし、AMLのリスクスコアを税務分類に流用せず、制度ごとの根拠や権限、保存期間、監査ログを分けられるかを確認します。

FATCAXMLを生成できれば対応は完了ですか？

XMLが生成できても、それだけでは完了とはいえません。必須項目や形式を満たすXMLに加えて、データの出所や分類根拠、証明書の有効性を説明できる必要があります。さらに、確認・承認や提出結果、エラー対応、訂正・取消の履歴も、説明できる必要があります。

IRSのIDESでは、XML検証、署名、圧縮、暗号化、メタデータ作成を含む送信準備が必要です。

IRSのIDESは、送信後の通知にも対応しています（出典: IRS「IDES data transmission and file preparation」、2025年12月更新）。

FATCA対応システムをクラウドで運用しても問題ありませんか？

クラウドも選択肢になりますが、金融機関の委託先管理とセキュリティ審査を通す必要があります。

まず、保存地域や暗号鍵の管理者、管理者権限、テナント分離を確認します。続いて、アクセスログやバックアップ、復旧目標を見ます。さらに、脆弱性対応、再委託先、終了時の消去も確認します。

AMLなど別の用途にも使う場合は、目的外の利用にならないか、社内規程や個人情報の扱いも確認します。

まとめ

開発では、制度とIGA、提出先を確認したうえで、顧客属性と口座データを洗い出します。続けて、判定や証明書管理、XML、監査証跡を一つの業務フローとして設計します。

報告ファイルを作るだけでなく、対象とした理由や利用したデータ、承認者、訂正内容を後から説明できることが、成功の条件になります。

自社に合う開発方式の選び方

方式を選ぶ際には、法人やデータソースの数に加えて、既存基盤との連携や、制度別の統制要件を見ます。

• 限定導入：1法人・少数データソースなら、専門パッケージやSaaSが候補です。
• 複数商品・法人：AML・KYC、顧客マスター、データ基盤とのSI連携が必要になりやすいです。
• 複数制度の共通基盤：FATCA・CRS・AMLを同じデータ基盤で扱う場合でも、制度ごとの権限と証跡を分けられることが条件になります。

見積もり前のデータと責任分界の整理

対象データと責任分界を整理したうえで、規模別の予算幅や金額の変動要因、費用項目、社内の受入条件を合わせて確認します。

• 規模別の予算：小規模は800万〜2,000万円、中規模は2,000万〜6,000万円、大規模は6,000万〜2億円超が目安です。
• 金額の変動要因：データソース数、過去データ補正、対象国、連携、訂正報告、審査、規制改定によって変わります。
• 比較と合意：初期費用、ランニング費、追加変更費、保守範囲を分けて比べ、税務・業務・情シスで受入条件まで合意します。

▼全体ガイドの記事
・FATCA対応システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。