米国BSA/AML規制と法人確認：日本の金融機関が実践すべきCDDプロセス完全ガイド
米国との取引を行う日本の金融機関・フィンテック企業にとって、BSA AML 米国法人確認は避けて通れない実務課題です。米国銀行秘密法（Bank Secrecy Act：BSA）とアンチマネーロンダリング（AML）規制は、取引相手が本当に存在する適法な法人であるかを確認することを義務付けています。日本側では「犯罪による収益の移転防止に関する法律（犯収法）」や金融庁（FSA）のガイドラインが同様の要件を定めており、両国の規制を同時に満たすCDDプロセスの構築が急務となっています。
本ガイドでは、規制の背景から実際のAPIを使った法人確認の自動化まで、実務担当者がすぐに活用できる情報を体系的に解説します。
1. なぜ今、米国法人確認が重要なのか
米国BSA/AML規制の概要
BSAは1970年に制定され、FinCEN（金融犯罪取締ネットワーク）が執行を担います。2016年には顧客デューデリジェンス最終規則（CDD Final Rule）が施行され、金融機関は法人顧客の実質的支配者（Beneficial Owner）を25%以上の持分基準で特定・確認することが義務付けられました。さらに2024年施行の企業透明化法（Corporate Transparency Act：CTA）により、米国の法人・LLCはFinCENへのBOI（Beneficial Ownership Information）報告が必要となり、法人の実在確認の重要性がいっそう増しています。
日本の犯収法・FSA規制との整合性
日本の犯収法は、FATF勧告に基づき特定事業者（銀行・証券会社・保険会社など）に対してKYC義務を課しています。2023年の改正により、法人顧客の実質的支配者確認が強化され、登記情報との照合が実務上の標準となりました。金融庁の「マネー・ローンダリング及びテロ資金供与対策に関するガイドライン」では、リスクベースアプローチ（RBA）のもと、海外法人との取引はより厳格なCDDが求められると明記されています。
つまり、米国法人と取引する日本の金融機関は日米双方の規制を満たす法人確認プロセスを整備しなければなりません。
2. 米国法人確認の実務：Secretary of State記録の活用
Secretary of State（州務長官）データとは
米国では各州のSecretary of State（州務長官）が法人・LLC・パートナーシップの登録を管理しています。日本の法務局が発行する「登記事項証明書」に相当するものです。この公式記録には、法人名・法人種別・設立日・登録エージェント・現在のステータス（Active/Dissolved等）が含まれており、CDDの一次情報源として最も信頼性が高いとされています。
手動確認の限界
米国50州＋ワシントンD.C.・プエルトリコ・米領ヴァージン諸島それぞれに独自のポータルがあり、UIも検索仕様も異なります。大量の法人を手動で確認するのは非効率であり、ヒューマンエラーのリスクも高まります。これを解決するのがOpenSOSDataのようなAPIサービスです。
3. OpenSOSData APIによる自動化
OpenSOSDataは、全米50州＋D.C.・プエルトリコ・米領ヴァージン諸島をカバーし、3,400万以上の法人情報をRESTful APIで提供します。CDDワークフローへの組み込みに最適化されており、以下の情報を返します。
- 法人名・法人種別（LLC、Corporation等）
- 法人固有ID（State Entity ID）
- 現在のステータス（Active / Dissolved / Revoked等）
- 設立日
- 登録エージェント名・住所
料金体系（USD）
| クエリ種別 | 標準単価 | 大口単価（最安） | 参考JPY（1USD=150円） |
|---|---|---|---|
| ライブルックアップ（リアルタイム） | $0.10 | $0.0314 | 約15円〜4.7円 |
| キャッシュルックアップ（高速・低コスト） | $0.01 | $0.00314 | 約1.5円〜0.47円 |
従量課金制のため初期費用ゼロ。まずはアカウント登録してAPIキーを取得してください。
curlによる基本的なルックアップ例
# ----------------------------------------------------------------
# OpenSOSData API - 米国法人ライブルックアップ（curl）
# CDDプロセスでDelawareのLLC存在確認を行う例
# ----------------------------------------------------------------
curl -X POST https://api.opensosdata.com/v1/lookup \
-H "Content-Type: application/json" \
-H "x-api-key: YOUR_API_KEY" \ # APIキーはヘッダーで渡す
-d '{
"entity_name": "Acme Trading LLC", # 確認対象の法人名
"state": "DE", # デラウェア州を指定
"cache_preference": "live_only" # リアルタイム取得（CDD推奨）
}'
Pythonによる実装例（バッチCDDワークフロー）
import requests
import json
# ----------------------------------------------------------------
# OpenSOSData API - Pythonによる法人確認バッチ処理
# 複数の取引先法人をループで確認するCDDユースケース
# ----------------------------------------------------------------
API_KEY = "YOUR_API_KEY" # 環境変数から取得することを推奨
API_URL = "https://api.opensosdata.com/v1/lookup"
# 確認対象の法人リスト（法人名・州のペア）
target_entities = [
{"entity_name": "Acme Trading LLC", "state": "DE"},
{"entity_name": "Pacific Ventures Inc", "state": "CA"},
{"entity_name": "New York Holdings Corp", "state": "NY"},
]
headers = {
"Content-Type": "application/json",
"x-api-key": API_KEY # 認証はx-api-keyヘッダーを使用
}
for entity in target_entities:
payload = {
"entity_name": entity["entity_name"],
"state": entity["state"],
"cache_preference": "live_only" # CDDにはライブ取得を推奨
}
response = requests.post(API_URL, headers=headers, json=payload)
if response.status_code == 200:
data = response.json()
print(f"法人名: {data.get('entity_name')}")
print(f"ステータス: {data.get('status')}") # Active確認が最重要
print(f"設立日: {data.get('formation_date')}")
print(f"法人種別: {data.get('entity_type')}")
print("---")
else:
# エラー時はCDDエスカレーション対象として記録
print(f"確認失敗: {entity['entity_name']} - {response.status_code}")
詳細なAPIリファレンスは公式ドキュメントを参照してください。
4. CDDプロセスへの組み込み：実務フロー
推奨CDDワークフロー
- 法人情報の収集：取引先から法人名・設立州・EIN（雇用者識別番号）を取得
- Secretary of State確認：OpenSOSData APIでステータス・設立日・登録エージェントを確認（
cache_preference: live_only推奨） - 実質的支配者の特定：CTAのBOI情報およびFinCEN要件に基づき25%超の持分保有者を特定
- 制裁リスト照合：OFAC SDNリスト・国連制裁リストと照合
- 記録保管：犯収法・BSA双方の要件に従い5年間保管
- 継続的モニタリング：定期的にAPIを使って法人ステータスの変化（Dissolvedへの変更等）を監視
cache_preferenceの使い分け
| 値 | 用途 | コスト |
|---|---|---|
live_only |
CDD・口座開設時など最新情報が必須の場面 | $0.10〜 |
cache_first |
コスト効率重視・速度優先のスクリーニング | $0.01〜（キャッシュヒット時） |
cache_only |
大量バッチ処理・事前調査フェーズ | $0.01〜 |
5. 日米規制対応チェックリスト
- ✅ 米国法人のSecretary of Stateステータスをリアルタイムで確認している
- ✅ 設立州・法人種別（Delaware LLC等）を記録している
- ✅ CTAに基づくBOI情報の収集手順を整備している
- ✅ 犯収法に基づく実質的支配者確認記録を5年保管している
- ✅ FSAガイドラインのリスクベースアプローチを文書化している
- ✅ OFAC制裁リストとの照合を自動化している
- ✅ 法人ステータス変化の継続的モニタリングを実施している
よくある質問（FAQ）
Q. Secretary of State記録はKYC証跡として法的に有効ですか？
はい。米国各州のSecretary of State公式データベースは政府公式記録であり、BSA/AML規制下でのCDD証跡として広く認められています。日本の犯収法においても、外国法人の「本国での法人登録証明」に相当する一次情報源として活用できます。ただし、単独では不十分な場合もあるため、実質的支配者確認・制裁リスト照合と組み合わせて使用することを推奨します。
Q. DelawareのLLCが特に多い理由は何ですか？
デラウェア州は法人税制の優遇・柔軟な会社法・確立された判例法から、米国で最も設立件数が多い州です。日本企業が米国進出時にデラウェアLLCを選ぶケースも多く、取引先がデラウェア設立である場合は特に慎重なCDDが求められます。OpenSOSData APIではデラウェア州（state: "DE"）の照会も完全対応しています。
Q. 法人番号（houjin bangou）と米国EINの関係は？
日本の法人番号（13桁）は国税庁が付番する法人固有識別子です。米国のEIN（Employer Identification Number）はIRSが付番する税務識別番号で、機能的に近い存在です。ただしEINはSecretary of Stateのデータには含まれないため、KYB目的では州レベルのEntity IDとEINを別途管理する必要があります。OpenSOSData APIはState Entity IDを返します。
Q. cache_preferenceでlive_onlyとcache_firstはどう使い分けますか？
CDD・口座開設・大型取引承認など最新情報が法的に必要な場面ではlive_onlyを使用してください（$0.10/件〜）。一方、既存取引先の定期スクリーニングや事前リサーチフェーズではcache_firstやcache_onlyでコストを抑えられます（$0.01/件〜）。コンプライアンス方針に応じてワークフローごとに設定することを推奨します。
Q. 全50州対応とはどういう意味ですか？カバレッジに穴はありますか？
OpenSOSDataは米国50州＋ワシントンD.C.＋プエルトリコ＋米領ヴァージン諸島の公式Secretary of Stateデータをカバーしており、3,400万件以上のエンティティが検索対象です。各州のデータ更新頻度はライブルックアップ時に州公式データベースをリアルタイム参照するため、最新の登録情報が取得できます。詳細はAPIドキュメントをご確認ください。
Q. 日本のFSAへの報告にそのままAPIレスポンスを使えますか？
APIレスポンスのデータ（法人名・ステータス・設立日・登録エージェント等）は証跡として記録・保管できますが、FSAへの報告書類にはシステムログとして取得日時・検索パラメータも合わせて保管することが重要です。犯収法上の取引時確認記録（第4条）の要件を満たすよう、自社のコンプライアンス部門と照合したうえで活用してください。
Q. 無料トライアルはありますか？
従量課金制のため初期費用・月額固定費は不要です。アカウント登録後すぐにAPIキーを取得してテスト環境で試すことができます。まず少量のクエリから始めて、CDD要件に合ったワークフローを構築することをお勧めします。
まとめ
米国BSA/AML規制と日本の犯収法・FSAガイドラインの双方を満たすCDDプロセスを構築するには、Secretary of Stateの公式記録を起点とした法人確認の自動化が不可欠です。OpenSOSDataのAPIを活用することで、全米の法人情報をリアルタイムかつ低コストで取得し、コンプライアンスワークフローに直接組み込めます。
まずは無料アカウントを作成して、自社のCDDフローに組み込んでみてください。APIの詳細仕様は公式ドキュメントで確認できます。日米クロスボーダー取引における法人確認の精度と効率を同時に高め、規制リスクを最小化しましょう。