金融系とシステムの真面目な話【決済面】

決済におけるシステムとの関係

なるべく専門的な用語を使わないようにしますので、かなり概要的な話に留めます。

基幹系システムと分散系システム

特に金融機関のシステムを語るにあたっては基幹系（「メインフレーム」とも）と分散系（「オープン系」とも）の話はどうしても出てくるので、ここでも概要レベルで取り上げます。

大雑把かつ極論を言えば、基幹系はスーパーコンピュータ等の大規模なシステム、分散系はパソコン（勿論、個人向けPCよりは高性能になりますが）位の差があります。

具体的な差は以下の通りです。ここで話をするにあたって必要な項目に絞っています（本当はもっと一杯差があります）

基幹系システムとバッチ処理

数十万や数百万の会員や決済数がある会社の取引データを分散系システムのみで賄うのは不可能ではない＊ですが現実的ではありません。＊それこそブロックチェーンのように並列で多数配置すれば理論上は可能かも。

その為、各社では、メインフレームと呼ばれる基幹系システムを構築して、大量データの「バッチ処理」＊を行っています。＊オペレータが直接入力する「オンライン処理」もありますが、メインフレームはバッチ処理が主体です。

「バッチ処理」は自由度はなく、決められた時間に決められた処理を行います。その為、項目名やデータの長さ、処理内容等が予め決められています。

基幹系システムの弱点

先ほど、項目名等が予め決められていると言いました。つまり、後から「この項目を新たに追加したいんだけど」というニーズが発生しても、簡単には対応できません。

システム上、項目追加は不可能とは言いませんが、図の通り、社外とのインプットやアウトプットにも影響してくるため、開発だけではなく社内外含めた広範囲での影響調査が必要となってきます。

調査の結果、データ量や処理量に大きな影響を及ぼす場合は、対応不可（項目追加自体が出来ない。処理能力が不足する）となる場合もあります。

例えば、10年前に構築したシステムは10年前までの業務ニーズ（業務要件）に基づいた項目等が設定されており、その後発生するニーズに即応するのは困難です。

つまり、システム導入から年数がたてば経つほど、時代のニーズに合わせた対応が困難になる可能性が高いと言えます（基幹系・分散系問わず、システム全般に言える事ですが）。

言いたい事

基幹系が保有するデータを元に、会員向けのWebサービスや販売促進等のサービス展開も行っています。裏を返せば、基幹系が保有していないデータを必要とするサービスは展開できない、という事になります。

システム更改に注目する理由

多田野が決済関連会社のシステム更改や構築に注目する理由は、決済関連会社では処理能力が企業活動の命だからです。

システム周りの動きでは、クレジットカード会社では、2017年にクレディセゾンが基幹系システムの更改を行い、三井住友カードも2017年に全面刷新しています。JCBは2008年のJENIUSが最新。

一方で、三菱UFJニコスはシステム統合に何度か躓いており、例えば各社の会員向けのWebアプリの充実度の差異には、特に基幹系システムの設計の新しさ古さといった差異も要因の一つになると考えています。

以前、エポスカードについて書いた記事（下記参照）で「メインフレームが古い」という考察を書きましたが、上記のような理由から考察に至っています。

クレジットカード会社以外は？

”伏線回収”という意味もあり、主にクレジットカード会社の話を書きました。各社ともに、基本的に自社でデータプロセッシング業務を行っています。

但し、アメリカではクレジットカードのプロセシング業務はアウトソーシングするスタイルが主流です。

QRコード決済は、例えばPayPayで言えばGMO-PG等の決済代行会社に委託している様です（他社も同様と推察）。決済代行会社についてはまた別の機会に。

データプロセッシングはスケールメリットを享受できる業務（逆に言えば、小ロットではコスパが悪い）なので、少額決済主体のQRコード決済では自前運営しない方が自然だと思います。

金融系でも、新生銀行やソニー銀行などはオープン化やクラウド化を行っていますが、規模の大きくない（処理量の大きくない）会社だから実現可能という部分もあると思います。

かなり端折った内容とはなりますが、システム的な面から少し真面目な話をしてみました。