グローバル企業の課題 – マルチバンク対応

By 最高技術責任者 石黒直裕 2014年9月3日

グローバル展開をしている日系企業は、邦銀、外銀、現地行と取引があり、グループ全体の資金管理を行う際には、それらの銀行全てとシステムの接続をして、銀行取引明細の取得や送金指図の送信を行う必要がでてきます。
特に最近はグローバルM&Aの増加により、新たに買収した会社の主要取引行が現地行で、見える化が早急に必要というケースも多いのが事実です。

また海外では61%の企業が支払の不正(未遂を含む)を経験しており(AFP、2013年)、過去7年で不正は72%も増加しています(FBI、2012年)。海外子会社を多く傘下にかかえる日系企業にとっては、銀行と繋ぎ、本社が子会社の支払を見られるようにすることは必須です。
世界で複数の銀行とシステム接続を実装し、運用していくこと(ここでは「マルチバンク対応」と呼ぶ)についての、ポイントをご紹介します。

 

1. マルチバンク対応システムと接続方法を選ぶ

 

(1)システムを選ぶ

 

システムの候補としては銀行のCMSもしくはベンダーのソリューションがあり、その中で、海外を含めて取引行すべてと接続ができるシステムを選ぶことになります。
銀行の場合、「グローバル対応」という表現であっても、グローバルで自行のみに対応するのか、グローバルで他行も含めて対応できるのか、両方とも「グローバル対応」と言うので確認が必要です。
ベンダーの場合は、もとよりマルチバンク対応ですが、念のため、自行の取引行が接続可能か、確認はするべきです。

 

銀行との接続方法とは、どの通信プロトコル(ネットワーク上で通信をする際の手順)で、どのファイル・フォーマットでデータを送受信するのか、ということです。コストとIT統制の面から、基本的にはグローバルで一つのプロトコルとフォーマットに統一するのが理想ですが、銀行によって対応できる方法が異なるので、接続可能なプロトコルとフォーマットが豊富なシステムを選ぶのがよいといえます。

 

(2)接続の通信プロトコルを選ぶ

 

まず、どの通信プロトコルで銀行とデータの送受信をするかを決めます。日本国内では全銀手順が標準ですが、世界の標準としてはSWIFTです。銀行は、SWIFT及びその国のプロトコル、もしくはその国のもののみに対応している場合が多いと思われます。ベンダーのソリューションは、SWIFT及び各国のプロトコルに対応しているものもあります。
特段の要件がない限り、極力グローバルで一つにまとめるべきだと考えます。国ごとに通信プロトコルを変えると、それぞれにネットワーク利用のためのシステム資源が必要になり、重複費用も発生するからです。

 

よって原則的にはSWIFTで考えたい。しかし銀行側でSWIFTに対応できない場合もあるので、その場合は、銀行が対応できるプロトコルにするか、代替手段を考えるべきです。
実際、欧米の企業は、グローバルでSWIFTを標準とし、地域や国固有の対応は原則として認めないところが多く、アメリカは、SWIFTよりも銀行と直接接続すること(ホスト間接続、”Host-to-Host”)が殆どですが、グローバルで標準化、統一する強い意志を持っている点は同じです。

 

(3)ファイル・フォーマットを選ぶ

 

銀行と送受信をするファイルのフォーマットには、SWIFT標準のフォーマット、国や地域の標準フォーマット(日本でいえば全銀)、銀行固有のフォーマットがあります。銀行は、SWIFTとその国のフォーマット、もしくはその国のフォーマットのみに対応している場合が多く、ベンダーのソリューションは、SWIFTや各国のフォーマットに加えて、世界主要行の個別フォーマットに対応しているものもあります。

 

業務要件からSWIFTよりも当該国のフォーマットの方がよいこともあるでしょう。銀行によってはフォーマットによってデータ送受信の料金が異なることもあります。一般論としてはコストも含めた長所短所の比較をして決めることになりますが、欧米企業ではプロトコルと同様にフォーマットも統一傾向が顕著になっています

 

ポイント:グローバルで邦銀、外銀、現地行と接続できるシステムを選択する。基本的にはSWIFTをベースとするが、将来性も考え、対応プロトコルと対応フォーマットが豊富なシステムを選び、極力プロトコルとフォーマットを統一させる。

 

2. マルチバンク対応システムを導入する

SWIFTのフォーマットは標準であるが、項目の設定方法などの詳細については銀行の裁量に委ねている部分もあり、銀行個別の仕様が存在します。結果、SWIFTを選択しても、導入時には、銀行個別にサンプルファイルをもらって仕様を確認し、テストをすることが欠かせません。また銀行固有の仕様に対してシステムの修正が発生するかもしれません。
したがって、ベンダーに取引行ごとにこれらの作業を全て行ってもらう必要があり、銀行の場合は、本業ではないので、どこまで作業を頼めるか、ご相談になることが想定されます。

そのベンダーに当該行と既に接続実績があれば、この確認やテストの作業が殆ど不要になるため、導入工数、ひいては導入コストが減ります。

ポイント:グローバルで銀行接続実績が豊富なシステムとベンダーを選ぶ。ベンダーに、各銀行との個別作業の一切を取り仕切ってもらう。

 

3. マルチバンク対応システムを維持、運用する

日々のオペレーションでは、ネットワークとシステムの監視が必要である。グローバルでは時差の関係で、常にどこかの銀行とはデータの送受信が発生しています。
例えば銀行取引明細の場合、銀行からデータが届かなかった時に、銀行、ネットワーク、資金管理システムのいずれの問題か、切り分ける必要があり、そして原因が判明したら、そのエラーを復旧させる必要があります。このような作業をベンダーにしてもらわないといけません。

 

将来について言えば、SWIFTは毎年更新がある上、新しい制度や規制、標準も出てきます。最近の例では来年に欧州でSEPAへ移行し、マルチバンク認証システム3S Keyへのニーズも高まっています。このような将来の追加・変更への対応を続けてくれるシステムおよびベンダーを選ぶことが必要になります。

 

ポイント:グローバルで24時間365日、銀行とのデータの送受信を監視し、障害時にはサポートしてくれて、そして将来に亘って制度や標準の更改・追加に対して迅速に対応してくれるベンダーを選ぶ。

 

まとめ

 

筆者はグローバル財務管理ソリューションのベンダーの人間ですが、マルチバンク対応に限って言えば、銀行よりはベンダーのソリューションの方が有力な選択肢という結論に至ります。世界での接続方法に対する対応度合い、日々の運用監視、将来への対応までも含めて考えると、マルチバンク対応を本業としているベンダーの方が、最初からマルチバンクを前提にシステムを設計し、サポート体制を整えているためです。
そもそも銀行が対応しきれない範囲をサポートすることがベンダーの存在価値だと考えます。欧米でベンダー製品を採用するのは銀行に対する交渉力をあげたいという理由も大きいことを最後に補記したいと思います。

img
エンタープライズ
リクイディティ

流動性を活性化し、企業の成長と価値創造につなげます

詳細はこちら