よくある質問

「銀行ファイルフォーマット」とは?

1. ファイルフォーマットとは

銀行との間で銀行取引明細や送金指図など（以下、データと総称）を送受信するためには、データ・ファイルのフォーマットを決めなくてはなりません。

フォーマットとは、データ・ファイルのレイアウトや項目の設定仕様のことです。つまり送受信するファイルの何バイト目から何桁が口座番号か、何バイト目からが日付で、それは何の日付かといったファイルの仕様です。このファイルが銀行と財務管理システム（以下、TMS）双方で読み書きできるものでなければ、データを受け取る側が処理をできません。

2. フォーマットの種類

ファイルのフォーマットは、標準化されたものから、その銀行固有のものまであります。標準フォーマットも、世界レベルで標準のものから、ある地域や国で標準のものまで多種多様です。

① 世界標準フォーマット
TMSと銀行との間でデータの送受信を行う際に世界標準となっているのが、SWIFTのフォーマットです。SWIFTとは、1973年に金融機関が出資してベルギーで設立された共同組合形式の団体で、国を超えた銀行間のデータ連携の仕組みを標準化し、ネットワークを運営しています。入出金明細については、MT940、MT942（イントラデイ）、送金であれば MT101 や MT103、MT202 が代表的な SWIFT フォーマットです。このほか、2000 年代後半から制定が始まった、ISO 20022（金融業務で使用されるXMLメッセージの標準化に関する国際規格）のcamt（Cash Management：入出金明細）とpain（Payments Initiation：送金）も標準フォーマットの一つです。こちらはXMLの長所を活かし、より多くの情報量をファイルに格納でき、開発効率などもよく、次世代の標準とされています。

② 国や地域の標準フォーマット
国ごとの標準フォーマットとは、当該国の標準化団体・組織が制定している標準フォーマットのことで、日本でいえば全銀フォーマットなどがこれに該当します。全国銀行協会連合会（通称、全銀協）がデータ伝送を行うために定めたフォーマットです。

国ごとのフォーマットの例

国	標準仕様を制定している団体
イタリア	CBI
スペイン	AEB
フランス	CFONB (AFB)
ベルギー	FEBELFIN
ドイツ	ZKA (Zentraler Kreditausschuss)
日本	全国銀行協会

地域のフォーマットの例としては、EU が進めている SEPA（Single Euro Payment Area：単一ユーロ決済地域）における振込と引落の SEPA フォーマットがあります。このフォーマットも ISO20022 で規格が定められています。

③ 銀行独自のフォーマット
このほか、銀行独自のフォーマットを用意している銀行も多いです。また日本では ANSER のフォーマットもあります。ANSER は NTT データの ANSER サービス（残高照会や振込など、金融取引の利便性を高めるサービス）を利用する際のフォーマットで、複数の銀行とこのフォーマットでデータ交換ができるため、銀行独自のフォーマットではありませんが、特定サービスのフォーマットであり仕様が公開されているものではないため、ここでは銀行独自のフォーマットに分類しておきます。

3. フォーマットの選択

相手方の銀行と自社の TMS が対応できるフォーマットを選択しなければなりません。銀行が対応しているフォーマットは銀行に問い合わせてください。銀行から回答を受け取ったら、TMS ベンダーにそのフォーマットに対応しているか確認してください。

このとき、理論的には以下のシナリオがあります。

◎ 銀行が対応しているフォーマットで、TMSが読み書きできるフォーマットが複数ある場合。
グローバルでTMSを展開することを考えた場合、基本的には、世界標準であるSWIFTかXMLを選択することになります。あまり悩まずに決まりますが、後述する留意点もあります。

◎ 銀行が対応していて、TMSが読み書きできるフォーマットが一つしかない場合。
他に選択肢がないので、このフォーマットに決まります。

◎ 銀行が対応しているフォーマットのうちTMSが読み書きできるフォーマットがない場合。
TMSを改修して、そのフォーマットを読み書きできるようにするしか方法はありません。いいかえれば、将来性を考えた場合、対応しているフォーマットが多く、さらに弾力的にフォーマット開発を行ってくれるTMSソリューションを選択しておくことが肝要といえます。

◎ 銀行が対応しているフォーマットがそもそもない場合。
フォーマットがない銀行とは、インターネットバンキングなどもなく、紙の取引明細や通帳でしか銀行取引を行えないような銀行、つまりシステム化が極めて遅れている銀行です。とくにアジアの地場銀行などでは、そのような銀行は少なくなく、日系企業がTMSを入れて見える化する場合に大きな課題になることがあります。この場合は、銀行にデータを出してくれるよう依頼するしかありませんが、現実的には無理で、TMS に手入力することになります。

4. フォーマット選択時の留意点

① 世界標準 vs 国・地域標準
銀行がすべてSWIFTやISOのフォーマットに対応していれば、世界標準を軸にシンプルに決まるはずです。しかし、世界標準よりも、国や地域のフォーマットの方がよい場合もあって、実際のフォーマット選択の現場では、複数の選択肢の比較を行うことになります。

国や地域のフォーマットの方がよい場合とは、その国や地域のニーズにあわせて育ってきたフォーマットであるがゆえに、その国や地域にとっては、そのフォーマットが一番情報量をもっている場合があります。具体的にたとえば、邦銀の場合、全銀フォーマットではなく、SWIFT のフォーマットで取引明細をもらうとしたときに、全銀ではカナで入っている振込人名が SWIFT のフォーマットではローマ字になる場合が多いようです（銀行によります）。たとえば ｷﾔﾉﾝ は KYANON、ｱｲﾋﾞｰｴﾑ は AIBIEM などとなって読みにくくなり、業務の効率性が損なわれます。企業の中には自社システムに独自の辞書を組み込んでローマ字をカタカナに戻しているところもあるくらいです。また銀行によっては SWIFT のフォーマットで出す時に、必要最低限の情報しかSWIFTフォーマットにコピーしないところもあります。そうなると、その銀行取引の詳細がわかりにくくなるうえに、入出金予測やERPの会計データとの自動照合ができなくなることが起きます。

したがって、世界標準を基本としつつも、一部の国や地域では固有フォーマットで対応することが現実的な対応となります。

② 銀行の「変形」フォーマット
銀行が世界標準、もしくは国・地域の標準フォーマットに対応しているとしても、細かいところで銀行による差は出てきます。標準仕様では何をセットするかは規定してあっても、どのようにセットするかは銀行の裁量に任せている部分もあるためです。特に、XMLのISOフォーマットは、自由度の高いXMLファイルであることも相俟って、銀行ごとのバリエーションは非常に多くなっています。

導入時には、必ず早い段階で銀行からサンプルファイルと、そのファイル仕様書を取り寄せ、確認やテストを行うことが必須です。そして何等かの問題がある時には、TMS側で改修対応をする必要があります。とくに送金指図のファイルについては、完全に銀行指定の仕様でファイルを作成できないと送金が正しく行えないため、とくに慎重な確認作業が不可欠です。逆に言えば、銀行別のバリエーションに対応してくれないTMSベンダーを選んでしまうと、プロジェクトの途中で、送金ができないことが発覚するなどということにもなりかねません。