フィンテック精算システム
決済会社と銀行のデータを照合し、日次精算を自動で締められるようにしました。
- 開発期間
- 約6か月
- 体制
- 5名
- 対応プラットフォーム
- ウェブ · サーバー
- 連携システム
- 決済代行会社 · 銀行データ
背景
決済代行会社から届く取引明細と銀行の入金明細を、担当者が毎日Excelで突き合わせていました。件数が増えるにつれて照合作業が1日で終わらなくなり、締めが遅れると次の精算にも影響が出ていました。
実装範囲
- 決済代行会社・銀行データの収集
- 取引明細の自動照合
- 不一致案件の例外処理画面
- 日次精算締め処理
- 精算結果レポートの生成
- 精算履歴の照会
技術選定
その状況で何をなぜ選んだか照合結果を自動確定せず、例外案件のみ担当者確認後に締める運用
金額が関わる精算のため、システムが自動的に確定してしまうと誤りがあっても発見が遅れます。ルールに合致する案件は自動処理する一方、ルールから外れる案件は必ず人が確認・承認して初めて締められるようフローを分けました。
PostgreSQLで精算履歴を変更不可の形式で蓄積
精算データは後から「なぜこの金額だったのか」を遡れなければ監査対応になりません。締めが完了した精算案件は修正するのではなく訂正案件を新たに追加する形で残し、以前の状態が消えないようにしました。
技術課題
課題
決済代行会社ごとに取引明細ファイルの形式やフィールド名が異なり、単一の照合ロジックでは処理できませんでした。
アプローチ
決済代行会社別のファイルを共通の取引モデルへ変換するアダプター層を設け、照合ロジックはこの共通モデルだけを見るように分離しました。
結果
新しい決済代行会社が追加されてもアダプターを付け足すだけで済み、照合ロジック自体には手を入れる必要がなくなりました。
課題
銀行の入金が翌営業日にずれ込むことがあり、精算日と実際の入金日が異なる案件が毎日一部残っていました。
アプローチ
精算案件に「照合待ち」状態を設け、入金が確認されないまま一定期間が経過すると担当者画面に別途まとめて表示されるようにしました。
結果
精算日がずれた案件も漏れなく追跡され続け、締め後も確認が必要な案件を見落とさなくなりました。
引き継ぎと運用
精算担当者向けの運用マニュアルと例外処理基準の文書を併せて提供しました。ソースコードとインフラ構成を引き継ぎ、決済代行会社の追加連携は別途の保守範囲として合意しました。