【ITニュース解説】ACH Return Codes Explained: Handling R01–R85 in Production Payout Systems

ACH（Automated Clearing House）は、主に米国で利用される電子的な銀行間決済システムである。給与の直接預金、公共料金の自動引き落としなど、大量の取引を効率的に処理するために広く利用されている。このACHによる支払いが何らかの理由で失敗した場合、Nachaネットワークは単に「失敗」とだけ伝えるのではなく、具体的な失敗の原因を示す特別なコードを返送する。これがACHリターンコードであり、R01からR85までの85種類が存在する。これらのコードは、取引がなぜ跳ね返されたのか、そして次にどのような対応を取るべきかを明確に示してくれるため、信頼性の高い支払いインフラを構築する上で、システムエンジニアにとってその理解と適切な処理は極めて重要である。

ACHリターンコードは、Nacha運営規則に基づいており、それぞれのコードが異なる失敗モードを伝えている。システムは、これらのコードを単にログに記録するだけでなく、プログラム的に解読し、それに応じた適切な処理を実行する必要がある。リターンコードは通常、元の取引が送信されてから1〜2営業日後に到着する。ただし、同日ACH（Same-day ACH）取引の場合は、当日中の午前11時（米国中部時間）までにリターンが返ってくるのが一般的である。

システム開発において頻繁に遭遇する代表的なリターンコードとその対処方法を理解することは、トラブルシューティングと自動化の第一歩となる。例えば、R01は「Insufficient Funds（残高不足）」を示す。これは受取人の口座に取引に必要な金額が一時的に足りない状態であり、一時的で回復可能な問題である。この場合、システムはすぐに再試行するのではなく、24〜48時間程度の遅延を設けてから再試行するように設計すべきである。受取人が翌日には資金を補充する可能性があるためだ。

一方、R03は「No Account / Unable to Locate Account（口座なし／口座が見つからない）」を意味する。これは、指定された口座番号やルーティング番号が存在しないか、あるいは口座が既に閉じられているなど、永続的な失敗を示すコードである。このような場合、システムは対象の受取人情報を無効とマークし、速やかにユーザーに通知する必要がある。さらに、クレジットカードや電信送金、RTP（Real-Time Payments）といった代替の支払い方法を提示することが望ましい。

R04は「Invalid Account Number Structure（無効な口座番号形式）」である。これは、口座番号の桁数が多すぎたり、無効な文字が含まれていたりするなど、システム側のデータ品質に問題があることを示唆している。この種の失敗は、取引を送信する前にLuhnアルゴリズムや銀行固有のルールに従って口座番号を検証することで未然に防ぐことが可能である。

さらに、異議申し立てに関連するコードも存在する。R10は「Customer Advises Not Authorized（顧客が承認していない）」を示し、受取人が当該取引の承認を否定している状態である。これは紛争案件であり、システムは再試行を行うべきではなく、コンプライアンス部門による手動での調査が必要となるため、エスカレーションする仕組みが必要である。R29は「Corporate Customer Advises Not Authorized（法人顧客が承認していない）」であり、R10の法人版として同様に紛争として扱う必要がある。

R51は「Debit Initiated Without Authorization（承認なしでデビットが開始された）」を意味し、受取人の銀行がファイル上に承認を見つけられなかったために拒否されたことを示す。これは、受取人が定期的なデビット取引に対する再承認が必要な場合によく発生するため、システムは受取人に対して再承認を促すリクエストを送るべきである。

また、R82は「Duplicate Entry（重複エントリー）」である。これは、同じ金額、同じ日付、同じ口座に対する取引を二度送信してしまった場合に発生する。このような事態を防ぐためには、API連携において冪等性キー（Idempotency Key）を実装することが重要だ。R82を受信した場合は、再試行するのではなく、なぜ重複エントリーが発生したのかをシステム内で調査する必要がある。

これらのリターンコードを効率的に処理するためには、システム内に専用の「リターンハンドラー」を構築することが不可欠である。このハンドラーは、リターンコードの種類に応じて適切な処理ロジックを振り分ける役割を担う。例えば、R03やR04のような永続的な失敗コードは、口座を無効化し、ユーザーに通知し、代替手段を提案する処理にルーティングされる。R01のような一時的な失敗コードは、一定時間後に取引を再試行するスケジュールを作成する。R10やR29のような紛争コードは、コンプライアンス部門へエスカレーションする。その他の未処理のコードについては、将来的な分析のためにログに記録する、といった具合である。

リターンコードの処理にはタイミングの考慮も重要である。標準ACH取引の場合、リターンコードは1〜2営業日後に到着するが、多くのACHクレジット決済は取引の翌日（T+1）に完了する。しかし、リターンはT+2、あるいはそれ以降に届く可能性もある。このため、支払い取引が完了したと見なすのは、リターンを受け付ける期間（リターンウィンドウ）が閉じるまで待つことが賢明である。少なくとも2営業日の間は、支払いのステータスを「保留中」としておくことで、誤った成功通知を防ぎ、後の照合（Reconciliation）を容易にする。

もし特定の受取人に対してACHリターンが頻繁に発生する場合（例えば、R01が3回連続で発生するなど）、支払い方法の「レール」を切り替えることも検討すべきである。RTP（Real-Time Payments）は数秒で決済が完了し、即座にフィードバックが得られるため、より迅速な支払いが必要な場合に有効だ。また、Visa Directのようなカードリンク型のアカウントに対応したサービスも代替手段として考えられる。

結論として、すべてのACHリターンコードは単なるエラー表示ではなく、システムにとって価値ある「実行可能なデータ」である。リターンコードを、永続的な失敗、再試行可能なエラー、紛争、その他のカテゴリに分類し、それぞれに対応する処理を自動化するリターンハンドラーを構築することは、サポートの手間を削減するだけでなく、支払いルーティングの精度を高め、最終的にはユーザーエクスペリエンスを向上させる強力なシグナルとなる。プログラムによるACHリターンコードの解読は、安定した支払いシステムの構築を目指すシステムエンジニアにとって必須のスキルだと言えるだろう。