JP7843371B2 - リアルタイムでのデータの事前処理およびバリデーション - Google Patents

Description

発明の詳細な説明

［技術分野］
本発明は、金融業界に関し、より具体的には、事前の承認があればリアルタイムで口座間の送金を行う自動トランザクション処理のシステムおよび方法に関する。

［背景技術］
金融テクノロジーは急速に発展しており、特にキャッシュレス決済に関連するものが多い。オーバーレイサービスもそれらに属する。

オーバーレイサービスとは、（個人および法人向けの）様々な消費者向け決済サービスを改善するために開発されたソフトウェアおよびハードウェアサービスである。オーバーレイサービスは、セキュリティを向上させ、決済を簡素化し、場合によってはスムーズで摩擦のないものにする。金融業界では、オーバーレイサービスは、支払いまたは決済に先行することも、支払いまたは決済に後続することも、支払いまたは決済の前後に使用することも、支払いまたは決済とは無関係に使用することもできる。オーバーレイサービスは、どのような決済手段にも適用可能であり、カード決済（例えばミール（Ｍｉｒ）カード決済）、高速決済システム（Ｆａｓｔｅｒ Ｐａｙｍｅｎｔｓ Ｓｙｓｔｅｍ）による決済、デジタルルーブルを使用した決済、その他の決済手段に使用することができる。

金融業界における技術の脆弱性はリスクと結びついており、その信頼性と使用されるデータの安全性を維持しながら技術を発展させていくことが課題となっている。既存の技術は有効であることが証明されているが、より高度な信頼性メカニズム、特に決済トランザクション中の障害および不具合の発生確率を低減するメカニズム、ならびに不正トランザクションから保護するメカニズムが求められている。

（１）一国内での決済トランザクション、または（２）国境を越えた送金の両方をサポートするために設計された技術は数多く存在する。同時に、既知の技術は普遍的なものではなく、つまり上記の両方のトランザクションタイプに対応するように構成されておらず、決済トランザクションをサポートするすべての参加者のセキュリティと信頼性とを向上させるものではない。

例えば、世界的な銀行間金融通信システムであるＳＷＩＦＴシステムは、国境を越えた送金に適していることが証明されている。このシステムは、送金人側銀行と受取人側銀行、送金人側銀行と受取人側銀行のコルレス銀行といった金融機関間のメッセージングチャネルの安全性と信頼性とを保証している。送金を行うには、送金人はＳＷＩＦＴチャネルを使用するための支払命令の詳細を入力し、送金人側銀行に対する送金のための情報命令を生成する。その後、ＳＷＩＦＴシステムが支払命令を暗号化し、受取人側銀行に送信する。その結果、送金銀行のコルレス銀行は必要な金額を引き落とし、受取人側銀行のコルレス銀行に送金する。この方式では、資金の流れはリアルタイムで行われない。また、口座間の送金の直前に、送金条件の事前チェックと承認とを行う規定もない。つまり、内部エラーまたは受取人口座の凍結（例えば、差し押さえ）による失敗は否定できない。

国境を越えた決済トランザクションをリアルタイムで行うシステムおよび方法も当技術分野で知られている。このシステムおよび方法は、ある国の送金人が、送金人側銀行に接続された送金人側デバイス上のバンキングアプリケーションを使用して、別の国の受取人の口座への送金を開始する、既存の決済受付インフラストラクチャにおける国境を越えた送金の実行について説明している。国境を越えた送金は仲介銀行を経由して行われ、仲介銀行は所在国の決済システムとのチャネルおよび相互のチャネルを有している。送金のデータには、支払いの参照先、送金人側通貨での金額、トランザクション日の為替レートデータ、外貨への両替後の金額が含まれる。

その結果、国境を越えた決済は、送金人国および／または受取人国の１つまたは複数の仲介銀行による処理エラーおよび／または遅延に起因する国境を越えた決済の実行の遅延なく、リアルタイムで実行される（特許出願ＵＳ２０２１１８２８１０；Ｇ０６Ｑ２０／０２，Ｇ０６Ｑ２０／０８；２０２１年６月１７日公開）。

当該発明の欠点は、決済が行われる前に必要な事前チェックがすべてリアルタイムで行われないため、トランザクション中にエラーが発生する可能性が高いことである。従って、例えば、送金人が間違った受取人を選択した場合、そのエラーは受取人に入金された後に初めて発見されることになる。欠点には、事前の承認なしに資金の受取人を事前に特定できないという事実も含まれる。これは、例えばＡＭＬ（ａｎｔｉ－ｍｏｎｅｙ ｌａｕｎｄｅｒｉｎｇ）／ＣＴＦ（ｃｏｕｎｔｅｒ－ｔｅｒｒｏｒｉｓｍ ｆｉｎａｎｃｉｎｇ）制度（マネーロンダリング防止およびテロ資金供与対策）の下で、法律で定められたチェックなしに入金できることを意味する。従って、システムおよび方法には、送金の前に事前チェックを行い、支払準備を行う技術的能力がないというデメリットがある。これは、エラーおよび規制要件に違反するトランザクションが発生する可能性があることを意味する。他の例としては、受取人の口座が正しく入力されていなかったり、無効であったりすることがある。特許出願ＵＳ２０２１１８２８１０に記載されているシステムおよび方法は、手数料と両替レートとを考慮した、信頼できる最終送金額を含む支払命令を事前に生成するようには構成されていない。記載された技術は普遍的なものではなく、その条件を事前に確認することなく、国境を越えた送金を確実にするためのみに構成されている。

技術的解決策のもう１つの類型は、ある口座から別の口座への送金のための方法とシステムである。これにより、決済トランザクション開始後、同じ国にある送金人と受取人との口座間でリアルタイムで決済を実行することができ、この送金は既存の決済処理および受付インフラストラクチャで実行される。

その結果、信頼性を維持しつつ、送金の高速性が確保される（ＲＵ特許２７６１４１９；Ｇ０６Ｆ １７／００，Ｇ０６Ｑ ２０／０２；２０２１年１２月８日公開）。

当該発明の欠点は、適用範囲が狭いことである。その理由は、記載されているシステムおよび方法は、一国内の決済トランザクションにのみ適用可能であり、国境を越えたトランザクションを保証するように構成されていないからである。また、欠点には、決済トランザクションとそのチェックとが同時に実行されるという事実も含まれる。これにより、決済（資金の流れ）中のエラーおよび失敗の発生を排除することはできない。その結果、送金のスピードが低下する。

このように、現在のところ、オンライン送金の高い信頼性と安全性とを確保しながら、一国内および国境を越えた送金を行うための唯一の普遍的な技術は存在しない。

［発明の概要］
本発明が対象とする技術的課題は、一国内および異なる国間の送金をリアルタイムで実行するためのシステムおよび方法を構築することであり、そのために、詳細の信頼性（決済条件の「透明性」）と、送金人による受取人の識別とがより確保される。

技術的な成果としては、システムおよび方法が既存の決済受付および処理インフラストラクチャを使用するため、適用範囲が拡大し、一国内および国境を越えた送金の両方において送金のためにあらゆる決済手段を使用することが可能になること、為替レートおよび手数料の承認および計算なしで資金が流れるため、送金速度が加速されること、事前準備を経て資金が流れることにより、支払い拒否の可能性が減少し、送金の信頼性が向上すること、が挙げられる。

明示された技術的結果は、以下に詳述するシステムと方法とで達成される。

以下の用語を使用する：送金人側銀行とは、基準により定義された送金人である顧客にサービスを提供する信用機関の少なくとも１つのコンピューティングデバイスであり、顧客の指示により送金する際、そのコルレス口座から資金を引き落とさなければならない。

受取人側銀行とは、基準により定義された受取人にサービスを提供する信用機関の少なくとも１つのコンピューティングデバイスであり、資金の受取人に送金する際、そのコルレス口座に入金しなければならない。

仲介銀行は、仲介銀行、プロセッサ（例えば決済システム）、送金人側銀行、受取人側銀行など、他の信用機関のコンピューティングデバイスとの通信チャネルを有する信用機関の少なくとも１つのコンピューティングデバイスである。仲介銀行は、ＳＷＩＦＴまたはＳＰＦＳ（金融メッセージングシステム（Ｆｉｎａｎｃｉａｌ Ｍｅｓｓａｇｉｎｇ Ｓｙｓｔｅｍ））および／または他の決済システムを介してなど、個人の口座間で同一通貨および異なる通貨による口座間の送金を実行するように構成されている。

銀行（送金人側銀行、受取人側銀行、または仲介銀行）の少なくとも１つは、売りレートを決定し、買いレートを決定し、確立された規則に従って金額を両替するように構成されている。その機能を実行するために、両替を実行する銀行は、指定された買いレート、売りレート、および金額を両替するためのルールを取得するために、通信チャネルを介して少なくとも１つのデータベースにアクセスするように構成される。２つ以上のデータベースにアクセスする場合、両替を実行する銀行は、特定のトランザクションの売買条件を決定するように構成されている。本明細書におけるデータベースとは、通貨取引所を含むが、これに限定されるものではなく、例えばモスクワ取引所などの通貨取引所を意味する。両替を実行する銀行は、一定の時間に１回（例えば１日に１回）、および／または通貨レートが大きく変動する特定のイベントが発生したときに、レートを決定するために１つまたは複数のデータベースにアクセスする。

プロセッサ（電子決済処理のプロバイダー）は、銀行、決済システム（銀行の要件を満たす組織のソフトウェアとハードウェアの複合体、例えばロシア連邦中央銀行）などの様々な信用組織のコンピューティングデバイスとの通信チャネルを有する少なくとも１つのコンピューティングデバイスである。本明細書におけるプロセッサは、支払命令の生成と承認の段階において、情報技術の仲介者としても機能する。プロセッサは、特に、システムおよび方法の参加者間のメッセージの受信および送信、受取人側識別子による受取人側銀行の決定、メッセージデータのバリデーション、メッセージへの電子決済処理識別子の割り当て、前記識別子とメッセージに含まれるデータのリンク、識別子とデータの組み合わせのデータベースへの格納、リクエストに応じて前記識別子に基づいてメッセージに含まれるデータの提供を保証する。

プロセッサは、データフロープロバイダの機能と、決済センターの機能の両方を実行するように構成されている。一例として、プロセッサは決済システムであってもよい。決済システムとは、電子的なものを含む送金、メッセージの交換、実行のための送金命令の受け入れ、決済センターの機能など、規則と基準とに基づいて様々な金融トランザクションを実行するためのソフトウェアコンポーネントを有する信用機関である。また、決済システムは、送金人側銀行口座から資金を引き落とし、受取人側銀行口座に入金ための要求を生成して決済システムに送信し、決済システムからの応答を送金人側銀行および受取人側銀行に送信するように構成されている。

データフローとは、信用機関のコンピューティングデバイス間で一体的な論理ユニットを形成する一連のメッセージの転送であり、送金に関するデータを受信する。このデータには、支払人に関するデータ、支払人側銀行に関するデータ、決済システムに関するデータ、仲介銀行に関するデータ、受取人に関するデータ、受取人側銀行に関するデータ、送金額、および送金の際にシステム参加者が請求する手数料が含まれるが、これらに限定されるものではない。

送金人とは、銀行口座の所有者であり、データフローと送金人の指示処理とが成功した場合、その口座から送金することができる。

受取人とは、データフローにおいて特定された銀行口座の所有者である。当該データフローと送金人の指示処理とが成功した場合、その口座への送金が可能となる。

送金人側デバイス／受取人側デバイスとは、データフローを処理するときと支払いを行うときとの両方でトランザクションを実行するときに使用される個人用通信デバイスである。送金人側デバイスおよび受取人側デバイスには、システムまたは方法に従ってトランザクションを実行する能力を提供し、データフローおよび／または決済トランザクション処理に関するデータを交換し、情報を受信するユーザーインターフェースを備えたデバイスが含まれるが、これらに限定されない。例えば、携帯電話、コンピュータなどの個人用デバイス、または端末またはＡＴＭなどの公共用デバイスなどである。これらのデバイスに共通しているのは、送金人がそのデバイスのインターフェース上で送金人側銀行によって事前に認証される必要があることである。送金人と受取人とは、個人、法人、政府機関のいずれでもよい。

信用機関のコンピューティングデバイスは、顧客と、および信用機関同士でメッセージを交換する。当事者間のデータ交換プロセスを最適化するために、国際標準規格（例えば、国際標準規格 ＩＳＯ ２００２２、ＩＳＯ ８５８３）、または国際標準規格に基づく特定の決済システム用の標準規格が開発されている。これらには、当事者が交換できる情報とデータ形式（フィールド長、コード、文字セット）の明確な定義が含まれている。標準的なインフラストラクチャは、送金人と受取人側デバイス、銀行（送金人側銀行、受取人側銀行、場合によっては仲介銀行）、プロセッサ（決済システム（ＰＳ）のコンピューティングデバイス、例えば、ミール決済システム（Ｍｉｒ Ｐａｙｍｅｎｔ Ｓｙｓｔｅｍ）、高速決済システム（Ｆａｓｔｅｒ Ｐａｙｍｅｎｔｓ Ｓｙｓｔｅｍ）、ＳＥＰＡ、ＳＷＩＦＴ、その他の国際または国内の決済システムに適用可能）、決済システム（銀行の決済要件を満たす組織のソフトウェアとハードウェアとの複合体、つまり銀行間決済、例えばロシア連邦中央銀行）で構成される。説明したシステムおよび方法は、通信チャネルを使用して、そのようなメッセージを相互に交換するように構成されている。

受取人／送金人ＩＤは、電話番号、電子メールアドレス、あるいは受取人／送金人が口座を有する銀行にあらかじめ登録されたその他の識別子など、よく知られた社会的識別子である。受取人／送金人は、銀行によって安全に認証されなければならない。この場合、銀行は顧客が選択した少なくとも１つの銀行口座にこれらの識別子を割り当てることができる。

電子決済処理識別子は、実行された操作が、承認された支払命令に基づくリアルタイムの送金に先立つ支払命令の事前承認操作であることを示すとともに、次の電子決済処理スキームを可能にするために、プロセッサによってメッセージに割り当てられる一意の識別子である。プロセッサは、メッセージタイプ、すなわちプロトコル、つまり他のシステムコンポーネントおよびメッセージエントリーポイント（エンドポイント）との通信言語に基づいて、このような識別子を割り当てる必要性を決定する。例えば、当事者は、メッセージの送信と処理のためのＡＰＩを実装するＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）アーキテクチャスタイルを使用することができる。識別子の例：「ｐｒｅ－ｖａｌｉｄａｔｉｏｎ」または「ＬｏｏｋＵｐ」、あるいは「Ｓｅｔｔｌｅｍｅｎｔ Ｓｅｒｖｉｃｅｓ」データエレメントなど、電子メールデータエレメントに配置される別の値。

メッセージエンリッチメントとは、受取人にメッセージを送信する前に、オペレーションに必要なデータでメッセージをエンリッチするプロセスである。メッセージエンリッチメントに使用されるコンピューティングデバイスは、メッセージを自動的に処理するようにあらかじめ設定されている。

以下、本発明を図面により詳述する。

図１．１－第１実施形態に係る電子決済処理システム－データフロー。

図１．２－第１実施形態に係る電子決済処理システム－送金。

図２．１．１－第２国（受取人国）側プロセッサを有していない、第２実施形態に係る電子決済処理システム－データフロー。

図２．１．２－第２国（受取人国）側プロセッサを有していない、第２実施形態に係る電子決済処理システム－送金。

図２．２．１－第２国（受取人国）側プロセッサを有している、第２実施形態に係る電子決済処理システム－データフロー。

図２．２．２－第２国（受取人国）側プロセッサを有している、第２実施形態に係る電子決済処理システム－送金。

図２．３．１－第３国（仲介国／中継国）を有している、第２実施形態に係る電子決済処理システム－データフロー。

図２．３．２－仲介国／中継国を有している、第２実施形態に係る電子決済処理システム－送金。

図３．１－第１実施形態に係る電子決済処理方法－データフロー。

図３．２－第１実施形態に係る電子決済処理方法－送金。

図４．１－２つの仲介銀行を有している、第２実施形態に係る電子決済処理方法－データフロー。

図４．２－１つの仲介銀行を有している、第２実施形態に係る電子決済処理方法－データフロー。

図４．３－２つの仲介銀行を有している、第２実施形態に係る電子決済の処理方法－送金。

図４．４－１つの仲介銀行を有している、第２実施形態に係る電子決済の処理方法－送金。

［発明の詳細な説明］
本発明は、すべての必要なデータが準備され承認されるデータフロー内でのメッセージ交換を保証する。具体的には、トランザクションおよび参加者に関するデータが収集され、支払命令が承認される；送金人、受取人、支払いに関するデータが検証され、データフローに含まれる；レートおよび／または手数料を含むデータが記録される。準備作業は、リクエストがあれば即座に、つまりリアルタイムで実行される。この技術の特徴の１つは、準備が送金とは別に行われることであり、既知の類似技術とは異なり、共に行われることはない。このデータフローは、メッセージが前後に流れることでいわゆるデータループを形成する。

別個のデータフローの一部としてのデータの事前承認により、送金人は、送金を確認したり、拒否したりするために、送金の直前に、信頼でき、承認された送金条件を熟知することができる。また、準備行為により、受取人の口座状況を確認することで入金する技術的能力を事前に確立し、不正トランザクションを回避するために受取人を認識し、送金する前にエラーを特定し修正することが可能になり、エラーおよび失敗の可能性が大幅に減少する。それにより正しい詳細を使用した送金の中断のない実行が保証される。

以下は、例として提供され、本発明の実施形態を説明するための図面の説明である。

図１．１は、一国内のデータフローにおいて、送金のためのデータと条件の準備と承認が実行されるシステムを示している。図１．２は、送金のデータと条件の承認後、送金を保証する決済システムとの接続を示している。

図２．１．１は、第１国から第２国への送金のデータフローにおいて、送金の条件とデータの準備と承認とが実行されるシステムを示している。このシステムは、第１国側プロセッサを有していない、および／または、第２国側プロセッサを有していない状態で実行可能と理解される。

図２．１．２は、送金のデータと条件の承認後、送金を確実にする決済システムとの接続を示している。

図２．２．１は、データフローが実行されるシステムを示しており、第１国側プロセッサと第２国側プロセッサとの両方がシステムに参加している。

図２．２．２は、送金データと送金条件との承認後、送金を確実にする決済システムとの接続を示している。

図２．３．１は、第１国から第２国への送金のデータフローにおいて、仲介国のコンピューティングデバイスの関与のもと、送金データと送金条件との準備と承認とが実行されるシステムを示している。

図２．３．２は、第１国から第２国への送金データと条件との承認後、送金を確実にする決済システムとの接続を示している。

電子決済処理方法を開始するために、送金人は、デバイス上の支払者の銀行のユーザーインターフェース（個人口座の銀行のウェブページ上のブラウザ、または支払のためのウェブページ上のブラウザ、または送金人側デバイス上のユーザーインターフェース、または公共のデバイス（端末またはＡＴＭ）上のユーザーインターフェース）を介して送金を開始する。

図３．１は、一国内でのメッセージ処理方法を示している。

この方法は、例えば次のように実行される。

受取人の社会的識別子（例えば電話番号）が送金人側デバイスに入力され、送金額が指定されるか、受取人側識別子と送金額とを含む機械読み取り可能なタグが入力される。

その後、例えば、送金人のモバイルデバイスにインストールされているモバイルアプリからのリクエストに対しては、「Ｂａｎｋ Ａｐｐ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ（銀行アプリ確認リクエスト）」メッセージで送金リクエストが送信される。他のデバイスからの送金人のリクエストについても同様である。

送金人側銀行はメッセージを受信し、データをチェックし、送金人側銀行識別子とその他のデータ（オプション）とをデータエレメントに追加し、「Ｂａｎｋ Ａｐｐ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」としてプロセッサ（例えば、ミール（Ｍｉｒ）コンピューティングデバイス）に送信する。

プロセッサは、システム内の送金人側銀行登録をチェックし、メッセージに「ＬｏｏｋＵｐ」電子決済処理識別子を割り当て、受取人を特定し、「Ｓｅｑｕｅｎｔｉａｌ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ（シーケンシャル確認リクエスト）」メッセージフォーマットでデータを受取人側銀行に送信する。受取人は、受取人側識別子と受取人側銀行との組み合わせをデータベースから抽出することによって特定される。実施形態の１つによれば、「Ｓｅｑｕｅｎｔｉａｌ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージのデータは、電子決済処理識別子「ＬｏｏｋＵｐ」とともにデータベースに保存される。このステップにより、将来のデータ配列全体の転送を回避し、メッセージ処理識別子のみを転送し、リクエストに応じてデータを提供することができる。また、送金後にリクエストに応じてデータを提供することも可能である。このステップは、この送金オプションのみならず、この技術のすべての実施形態にも適用できる。

受取人側銀行もデータをチェックし、受取人側銀行識別子と入金準備の確認、および検証フレーズ（ＰＡＭ、Ｐｅｒｓｏｎａｌ Ａｓｓｕｒａｎｃｅ Ｍｅｓｓａｇｅ、たとえば受取人のフルネーム）のデータをエンリッチする。検証フレーズは、その後、受取人のデータを検証するために送金人に示すために使用される。

その後、「Ｓｅｑｕｅｎｔｉａｌ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ（シーケンシャル確認応答）」形式のメッセージによる応答が受取人側銀行から受信され、このメッセージがプロセッサに送信された後、「Ｏｒｉｇｉｎａｌ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ（オリジナル確認応答）」形式のメッセージによる応答がプロセッサから送金人側銀行に送信される。この応答には、入金額、入金準備の確認、送金人側銀行のデータ、受取人側銀行のデータ、送金人のデータ、受取人のデータが含まれている。したがって、この操作の結果は、支払命令の事前承認となる。

図３．２．は、支払命令の事前承認後、一国内での送金の方法を示している。

送金人は、承認された支払命令をデバイス上のユーザーインターフェースで受信すると、送金を開始することができ、その結果、送金人がそのような送金に同意していることを示すことができる。

例えば、送金人はモバイルアプリケーションのユーザーインターフェースで送金を開始する。その後、モバイルアプリケーションは「ＣｒｅｄｉｔＴｒａｎｓｆｅｒＲｅｑｕｉｅｓｔ（送金リクエスト）」メッセージを、送金リクエストと共に送金人側銀行に送信する。このメッセージには、受取人側銀行が支払いを入金する準備があることの確認と、送金額とが少なくとも含まれている。送金人側銀行はこのようなメッセージを受信し、それが事前に承認された支払命令であると判断し、その後、何度も確認することなく、そのメッセージをプロセッサ（この例ではミール（Ｍｉｒ）決済システム）に転送する。送金リクエストに基づいて、プロセッサは「ＣｒｅｄｉｔＴｒａｎｓｆｅｒＲｅｓｐｏｎｓｅＦｒｏｍＩＰＳ（ＩＰＳからの送金応答）」メッセージを生成し、送金人側銀行口座から資金を引き落とし、受取人側銀行口座に入金するという要求とともに決済システムに送信する。決済システムはこの要求を満たした後、「ＣｒｅｄｉｔＴｒａｎｓｆｅｒＲｅｓｐｏｎｓｅＴｏＩＰＳ（ＩＰＳへの送金応答）」メッセージをプロセッサに送り、要求が満たされたことを確認する。そして、「ＡｃｋｎｏｗｌｅｄｇｍｅｎｔＴｏＢｅｎｉｆｉｃｉａｒｙＢａｎｋ（受取人側銀行へのアクナレッジメント）」メッセージを送金人側銀行に、「ＡｃｋｎｏｗｌｅｄｇｍｅｎｔＴｏＩｎｉｔｉａｔｏｒＢａｎｋ（送金開始人側銀行へのアクナレッジメント）」メッセージを受取人側銀行に送信し、要求充足を確認する。その後、送金人側銀行と受取人側銀行から、それぞれ資金引落し通知と資金入金通知の「ＳｔａｔｕｓＲｅｐｏｒｔＴｏＩｎｉｔｉａｔｏｒ（送金開始人へのステータスレポート）」メッセージと「ＳｔａｔｕｓＲｅｐｏｒｔＴｏＢｅｎｉｆｉｃｉａｒｙ（受取人へのステータスレポート）」メッセージが送金人と受取人に送信され、その応答としてメッセージの送信確認がプロセッサに送信される。

図４．１は、国境を越えた送金のデータフローにおいて準備と承認とが行われる方法の一実施形態を示しており、２つの仲介銀行がこのスキームに参加している。この場合、データフローには以下に説明するメッセージが含まれる。

送金額と受取人側識別子とは、送金人側デバイスに入力されるか、このデバイスが、送金額と、社会的識別子、口座番号、銀行カード番号、銀行カードトークン番号、または仮想支払アドレスで表される受取人側識別子を含む機械読み取り可能なタグを読み取る。オプションとして、少なくとも受取人側銀行の国、受取人側銀行の名前、支払人側識別子、および支払参照番号を指定することができる。

第１国から第２国への送金の場合、金額を指定する際に、送金人側銀行通貨で送金人から引き落とす金額と送金人側銀行通貨とを選択するか、受取人側銀行通貨で受取人に入金する金額と受取人側銀行通貨とを選択することが一般的である。

送金リクエストは、例えば、送金人のモバイルデバイスにインストールされたモバイルアプリケーションで形成され、リクエストデータは「Ｂａｎｋ Ａｐｐ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージに配置される。

送金人側銀行はデータを受信し、それをバリデート（検証）し、送金人側銀行識別子、送金人側銀行口座番号、およびオプションとして追加データ（送金人のフルネーム、一意のメッセージ番号、送信日時、送金人側銀行名など）をそのデータにエンリッチし、「Ｏｒｉｇｉｎａｌ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージ内のデータを送信国側プロセッサ（たとえば、電子決済処理プロバイダーのコンピューティングデバイス）に送信する。

その後、プロセッサは、送金人側銀行識別子とシステムへの登録の事実とを確認し、「ｐｒｅ－ｖａｌｉｄａｔｉｏｎ」の電子決済処理識別子を生成し、受信したデータに前述の識別子をエンリッチし、第１国側仲介銀行の口座番号とその識別子とをデータにエンリッチした後、「Ｓｅｑｕｅｎｔｉａｌ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」形式のメッセージを第１国側仲介銀行に送信する。

その後、第２国側仲介銀行から「Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ ｆｒｏｍ １ｓｔ Ｉｎｔｅｒｍｅｄｉａｒｙ Ａｇｅｎｔ（第１国側仲介エージェントからの確認リクエスト）」メッセージとしてデータが順次送信される。

第１国側仲介銀行または第２国側仲介銀行が、送金人側銀行の通貨額を受取人側銀行の通貨額（またはその逆）に両替するための買いレートまたは売りレートを決定し、そのレートに関する情報をメッセージデータにエンリッチする。どちらの仲介銀行が売買レートを決定するかは事前に決められている。これは例えば、デフォルトの仲介銀行の１つであったり、送金リクエストが開始された国の仲介銀行であったりする。

その後、データは第２国側仲介銀行から第２国側プロセッサに「Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ ｆｒｏｍ ２ｓｔ Ｉｎｔｅｒｍｅｄｉａｒｙ Ａｇｅｎｔ（第２国側仲介エージェントからの確認リクエスト）」メッセージで送られる。次に、第２国（受取人国）側プロセッサと受取人側銀行とがメッセージを交換し、その結果、第２国側プロセッサは、第２国側仲介銀行の口座番号を含む「Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ ｆｒｏｍ ＬＵＰ２（ＬＵＰ２からの確認リクエスト）」フォーマットのメッセージを送信する。

受取人側銀行は、受取人の口座に入金する同意を確認し、受取人側銀行データ、受取人データ、ＰＡＭをメッセージにエンリッチし、「Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ ｔｏ ＬＵＰ２（ＬＵＰ２への確認応答）」フォーマットのメッセージで応答を送信し、図４．１に示すように、メッセージは送金人側デバイスに戻って送信される。

第１国側プロセッサおよび／または第２国側プロセッサは、国内決済システムコンピューティングデバイスおよび国際決済システムコンピューティングデバイスの両方であってもよい。

図４．２は、１つの仲介銀行を有しているスキームにおいて、第１国から第２国への送金のデータフローに準備と承認とが形成される方法の実施形態を示す。この実施形態は、プロセッサから仲介銀行へ「Ｓｅｑｕｅｎｔｉａｌ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」フォーマットのメッセージが送信される点で、前記実施形態と異なる。仲介銀行は、送金人側銀行の通貨額を受取人側銀行の通貨額（またはその逆）に両替するための買いレートまたは売りレートを定義し、そのレートに関する情報をメッセージデータにエンリッチする。そして、仲介銀行によってエンリッチされた送金データは、「Ｃｏｎｆｉｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ ｆｒｏｍ Ｉｎｔｅｒｍｅｄｉａｒｙ Ａｇｅｎｔ（仲介エージェントからの確認リクエスト）」メッセージとして第２国側プロセッサに送信される。

データフロー内でのメッセージ交換が完了すると、上述したように、データループが形成され（メッセージはまず送金人から受取人に送られ、その後戻ってくる）、また、送金人は送金人のモバイルデバイス、ブラウザ内のウェブページ、または公共のデバイス上で、送金に関する包括的で信頼性のあるデータを受け取るとともに、口座が有効であることを確認するために、受取人側銀行から入金するための同意、および口座が有効であり、凍結されていないことを確認するために、受取人側銀行から入金するための同意、さらに確認（例えば、ＰＡＭ（Ｐｅｒｓｏｎａｌ Ａｓｓｕｒａｎｃｅ Ｍｅｓｓａｇｅ）も受け取り、選択された受取人の正しさの信頼性を高めるために、送金人側デバイス上で送金人にその確認を表示する。

その結果、送金前に、すべての関係者のために送金のための包括的なデータが準備される。そのデータには以下が含まれていなければならない：
送金人とその口座に関するデータ、送金人側銀行が生成し提供する送金人側銀行に関するデータ；
受取人に関するデータ、受取人側銀行が作成し提供する受取人側銀行に関するデータ；
すべての参加者により一貫して生成されるトランザクションデータ（手数料と両替レート）を考慮した送金額。

その結果、手数料と両替レートとを考慮した合計金額が送金人側デバイスに送信される。

また、送金の開始は、資金の受取人のリクエストに応じて行うことができる。この場合、受取人は送金を開始するために承認された支払命令の詳細を提供する。このデータには、受取人側銀行名／識別子、支払命令識別子、および任意で送金額などの他のデータが含まれる。データは、リンク、ＱＲコードなど、機械で読み取り可能な任意の形式で提示することができる。

これに対し、送金人は、自らの判断で、送金人の口座から資金を引き落とし、受取人の口座に入金するよう、決済システムに要求を送ることができる。送金人が前のステップで生成されたデータを使用して送金する意思を確認した後、決済プロセスが開始される。

図４．３は、支払命令の事前承認後、２つの仲介銀行を有している、第１国から第２国へ送金される方法を示している。データフロー内のメッセージ交換の結果に基づいて送金を開始するために、承認された支払命令と、（データフロー内の）前のステップで生成された支払命令識別子とを含むメッセージが送金人側デバイスから送信される。承認された支払命令は、（データフローの一部として）前のステップで生成された支払命令識別子と、支払命令データとが含まれる。支払命令データには、送金人側通貨（第１通貨）または受取人国の通貨または他の通貨（第２通貨）での送金額、受取人側識別子（例えば、受取人側銀行カード番号、携帯電話番号などの社会的識別子、電子メールアドレスなどの形式）、さらに、受取人側銀行名、受取人側銀行の国（オプション）、および他のデータが示されることがある。

当該メッセージは、送金人側銀行に順次送信され、次に第１国側プロセッサに送信され、そこから第１国側決済システムに、送金人側銀行口座から第１国側仲介銀行の口座に第１通貨で送金する要求が送信され、その後、要求充足の確認が受信される。

その後、第１国側プロセッサは、要求充足の確認を含むメッセージを第１国側仲介銀行に送信し、さらに第２国側仲介銀行に送信する。

仲介銀行のうちの１つが、支払命令で指定された事前に承認されたレートに従って、資金の額を第１通貨から第２通貨に両替する。相互決済を行うために、第２国側仲介銀行の口座が第１国側仲介銀行に開設される（または、第２国側仲介銀行の口座が第１国側仲介銀行に開設される）。仲介銀行の少なくとも１つのコンピューティングデバイスが、メッセージから支払命令データを抽出し、資金を第１通貨から第２通貨に両替する手続きを開始する。

その後、第２国側仲介銀行からのデータが第２国側プロセッサに送られ、第２国側仲介銀行の口座から第２国の受取人側銀行の口座に第２通貨で送金するための要求が形成され、要求充足を確認する応答が受信される。その結果、事前に承認された支払命令に従って、第１国から第２国への送金が実行される。

図４．４は、支払命令の事前承認後、１つの仲介銀行を有している、第１国から第２国へ送金する方法を示している。この方法は、２つの仲介銀行を有している場合の方法と類似している。異なるのは、資金が１つの仲介銀行で事前に承認されたレートに従って、第１通貨から第２通貨に両替される点である。決済を行うために、仲介銀行で第１通貨の口座と第２通貨の口座とが開設される。仲介銀行のコンピューティングデバイスは、メッセージから支払命令データを抽出し、指定された仲介銀行の口座間で資金を第１通貨から第２通貨に両替する手続きを開始する。

第三国のコンピューティングデバイスが関与する電子決済の処理は、同様の方法で実行される。この場合、コンピューティングデバイスは上述した機能を実行し、この実施形態に係る電子決済の処理は、データフロー内の処理段階と送金中との両方に追加のステップを含む点で異なる。したがって、電子決済の処理は、仲介国を介した送金の場合、１カ国、２カ国、またはそれ以上の国の参加を得て実行することができる。

また、本発明は、第１国側プロセッサを有していない、および／または第２国側プロセッサを有していない状態で、電子決済を処理することを提供する。これらの実施形態では、送金も事前承認後に行われる。この場合、メッセージの処理および送信は、銀行（送金人側銀行、少なくとも１つの仲介銀行、および受取人側銀行）により、説明された機能に従って実行される。これらの銀行は通信チャネルを有し、システムおよび方法を実行するように構成されている。仲介銀行はまた、送金人側銀行と少なくとも１つの仲介銀行、または少なくとも１つの仲介銀行と受取人側銀行との間で、第１通貨から第２通貨に資金を両替するように構成されている。仲介銀行と送金人側銀行／受取人側銀行間の送金は、既知の方法による銀行間送金で行われる。

決済データの逐次生成には、データの整合性を監視するための操作の制御値の送信を（オプションとして）付随させることができる。メッセージ処理に関与する各関係者（銀行のコンピュータシステム、決済システム）は、送信されたデータの整合性を確実に監視するように構成されている。そのために、例えば特別なブロック（例えば「ｒｉｓｋ（リスク）」ブロック内）の配列を独立に生成された値の集合でエンリッチすることにより、オペレーション制御値（ｏｐｅｒａｔｉｏｎ ｃｏｎｔｒｏｌ ｖａｌｕｅ（ＯＣＶ））が送信メッセージ内に配置される。どの参加者も、以前に生成されたＯＣＶの値をチェックし、データフローにおいて計算されて含まれたＯＣＶをバリデートすることで、完全性をチェックすることができる。上述した手順により、様々な処理を実行する際にデータの完全性を維持するという点で、メッセージ処理のセキュリティがさらに向上する。

実施形態の１つによれば、送金の開始は、例えば、これに限定されるものではないが、高速決済システム（Ｆａｓｔｅｒ Ｐａｙｍｅｎｔｓ Ｓｙｓｔｅｍ（ＳＢＰ））を介して行われる。このような送金を実行するために、銀行は高速決済システム（Ｆａｓｔｅｒ
Ｐａｙｍｅｎｔｓ Ｓｙｓｔｅｍ）に接続する。送金開始人は、送金人または受取人である。送金人は、送金データを入力するか、受取人が用意した送金データを読み込んで、モバイルデバイス上のモバイルアプリケーションまたはブラウザ上のウェブページで支払いを開始する。ＳＢＰを介した送金の特徴は、各決済トランザクションについて、支払い中に決済システムによって資金が移動されることである。これを行うには、送金人側銀行からプロセッサ（例えば、ＯＰＣＣ ＳＢＰ － 高速決済システム（Ｆａｓｔｅｒ Ｐａｙｍｅｎｔｓ Ｓｙｓｔｅｍ）のオペレーショナルクリアリングセンター）にリクエストが送られる。ＯＰＣＣ ＳＢＰは次に、支払人側銀行口座から資金を引き落とし、受取人側銀行口座に入金する要求を生成し、決済システムに送る。第１国の送金人の口座から第２国の受取人の口座に送金する（ＳＢＰ経由の国境を越えた送金）には、第１国側プロセッサによって、送金人側銀行口座から資金を引き落とし、第１国側仲介銀行の口座に入金する要求が生成され、決済システムに送信される。決済システムは、例えば、ロシア連邦中央銀行または他の国の中央銀行の少なくとも１つのコンピューティングデバイスによって代表されることができる。決済システムはリアルタイムまたは遅延モード（所定時間中）で要求を満たし、要求が満たされた旨のメッセージを含む応答を決済システムに送信する。最後に、プロセッサは充足された要求事項に従って、資金の引き落としと入金の通知を銀行に送信する。図４．３および図４．４は、第１国から第２国へ送金する場合、送金人国の決済システムの場合と同様に、第２国側プロセッサによって生成されたリクエストに応じて、受取人国の決済システムでも口座間の送金のトランザクションが実行されることを示している。

記載されたシステムおよび方法によれば、送金に関与する２つの国の決済システムは、第１国から第２国への送金（国境を越えた送金）を、２つの銀行間送金（各決済システムにおける１つの送金）に絞り込むことができる。このように、それぞれの国の決済システムで１回ずつ（１回目は第１国の通貨で、もう１回目は第２国の通貨で）の送金を行うのみで、すべての手数料と両替レートを考慮し、送金データをチェックし、チェックサムを使って計算の正しさをチェックすることが可能になる。

上述の方法は、記載された電子決済処理システムを使用して実行することができる。記載されたシステムおよび方法は、緊急送金、非緊急送金、高速決済システム（Ｆａｓｔｅｒ Ｐａｙｍｅｎｔｓ Ｓｙｓｔｅｍ）を介した送金のメカニズムを使用した仲介国を介した送金を含め、一国内での送金および第１国から第２国への送金（国境を越えた送金）の両方に使用される。

このシステムおよび方法の利点は、送金の迅速化と信頼性の向上、事前準備の後に送金が行われることによる支払い拒否の可能性の低減、レートと手数料との承認および計算が不要であること、このシステムおよび方法は既存の決済受付および処理インフラストラクチャを使用するため、幅広い応用が可能であること、一国内および国境を越えた送金の両方で送金にあらゆる支払手段を使用することが可能であることである。

第１実施形態に係る電子決済処理システム－データフロー。 第１実施形態に係る電子決済処理システム－送金。 第２国（受取人国）側プロセッサを有していない、第２実施形態に係る電子決済処理システム－データフロー。 第２国（受取人国）側プロセッサを有していない、第２実施形態に係る電子決済処理システム－送金。 第２国（受取人国）側プロセッサを有している、第２実施形態に係る電子決済処理システム－データフロー。 第２国（受取人国）側プロセッサを有している、第２実施形態に係る電子決済処理システム－送金。 第３国（仲介国／中継国）を有している、第２実施形態に係る電子決済処理システム－データフロー。 仲介国／中継国を有している、第２実施形態に係る電子決済処理システム－送金。 第１実施形態に係る電子決済処理方法－データフロー。 第１実施形態に係る電子決済処理方法－送金。 ２つの仲介銀行を有している、第２実施形態に係る電子決済処理方法－データフロー。 １つの仲介銀行を有している、第２実施形態に係る電子決済処理方法－データフロー。 ２つの仲介銀行を有している、第２実施形態に係る電子決済の処理方法－送金。 １つの仲介銀行を有している、第２実施形態に係る電子決済の処理方法－送金。

Claims (26)

1. データの事前処理およびバリデートを、リアルタイムで個別に、かつ、電子決済トランザクションの前に行うためのシステムであって、
   送金人側デバイスと、
   送金人側銀行のコンピューティングデバイスと、
   受取人側銀行のコンピューティングデバイスと、
   メッセージングのための通信チャネルを有しているプロセッサと、を含んでおり
   前記送金人側デバイスは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、受取人側識別子および送金額を含むメッセージを前記送金人側銀行の前記コンピューティングデバイスに送信し、前記送金人側銀行の前記コンピューティングデバイスから応答を受信することによってデータフローを開始するように構成されており、
   前記送金人側銀行の前記コンピューティングデバイスは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、前記送金人側デバイスからメッセージを受信し、メッセージデータをチェックおよびバリデートし、前記送金人側銀行からのデータによって前記メッセージをエンリッチし、エンリッチされた前記メッセージを前記プロセッサに送信し、前記プロセッサから応答を受信するように構成されており、
   前記プロセッサは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、エンリッチされた前記メッセージを受信し、受取人側識別子によって前記受取人側銀行を特定し、エンリッチされた前記メッセージを前記受取人側銀行の前記コンピューティングデバイスに送信し、前記受取人側銀行の前記コンピューティングデバイスからの応答を受信し、その応答を前記送金人側銀行の前記コンピューティングデバイスに送信するように構成されており、
   前記受取人側銀行のコンピューティングデバイスは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、エンリッチされた前記メッセージを受信し、エンリッチされた当該メッセージを、受取人および前記受取人側銀行のデータと、前記受取人側銀行が入金する準備ができたことの確認とによってさらにエンリッチし、前記受取人側銀行が入金する準備ができていることを確認し、エンリッチされた前記メッセージを応答時に前記プロセッサに送信するように構成されており、
   前記プロセッサは、リアルタイムで個別に、かつ、前記電子決済トランザクションの前に、
   前記メッセージを一意に特定する電子決済処理識別子を生成し、
   電子決済トランザクションについての事前承認された支払命令と、電子決済トランザクションの実行時に後続して使用するための電子決済処理識別子とを含むメッセージを、前記送金人側銀行のコンピューティングデバイスを介して、前記送金人側デバイスに送信するように構成されている、
   システム。
2. 前記送金人側銀行の前記コンピューティングデバイスは、送金額と、前記受取人側銀行が入金する準備ができたことの確認と、送金が承認されたことを示す電子決済処理識別子と、を少なくとも含むエンリッチされた前記メッセージに対する応答を前記送金人側デバイスから受信し、このデータを前記プロセッサに送信するように構成されており、
   前記プロセッサは、送金人側銀行口座から資金を引き落とし、受取人側銀行口座に入金する要求を決済システムに送信し、要求が満たされたことの確認を前記決済システムから受信し、前記確認を前記送金人側銀行の前記コンピューティングデバイスと前記受取人側銀行の前記コンピューティングデバイスとに送信するように構成されている、
   請求項１に記載のシステム。
3. 前記決済システムは、各個別トランザクションの要求を満たすように構成されている、
   請求項２に記載のシステム。
4. 前記プロセッサは、受取人の口座にリンクされた少なくとも１つの受取人側識別子を、当該識別子によって前記受取人の口座を識別する能力を有するデータベースに格納するように構成されている、
   請求項１に記載のシステム。
5. 前記プロセッサは、電子決済処理識別子をメッセージに割り当て、リクエストに応じて前記メッセージのデータまたは前記データの一部を提供するために、前記電子決済処理識別子をデータベースに格納するように構成されている、
   請求項１に記載のシステム。
6. データの事前処理およびバリデートを、リアルタイムで個別に、かつ、電子決済トランザクションの前に行うためのシステムであって、
   送金人側デバイスと、
   送金人側銀行のコンピューティングデバイスと、
   受取人側銀行のコンピューティングデバイスと、
   第１国側プロセッサと、
   第２国側プロセッサと、
   メッセージングのための通信チャネルを有している、少なくとも１つの仲介銀行のコンピューティングデバイスと、を含んでおり、
   前記送金人側デバイスは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、受取人側識別子と送金額とを含むメッセージを前記送金人側銀行の前記コンピューティングデバイスに送信し、前記メッセージに対する応答を受信することによってデータフローを開始するように構成されており、
   前記送金人側銀行の前記コンピューティングデバイスは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、前記送金人側デバイスからメッセージを受信し、メッセージデータをチェックおよびバリデートし、前記送金人側銀行のデータによって前記メッセージをエンリッチし、エンリッチされた前記メッセージを前記第１国側プロセッサに送信するように構成されており、
   前記第１国側プロセッサは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、エンリッチされたメッセージを受信し、電子決済処理識別子を前記メッセージに割り当て、前記受取人側識別子によって前記受取人側銀行を特定し、エンリッチされた前記メッセージを前記電子決済処理識別子とともに前記仲介銀行の前記コンピューティングデバイスに送信し、前記仲介銀行の前記コンピューティングデバイスから応答を受信し、前記応答を前記送金人側銀行の前記コンピューティングデバイスに送信するように構成されており、
   前記仲介銀行の前記コンピューティングデバイスは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、エンリッチされた前記メッセージ内のデータを受信し、チェックおよびバリデートし、第１通貨における送金額と第２通貨における送金額とを前記メッセージにエンリッチするために、為替レートを用いて送金額を第２通貨における送金額に換算し、前記仲介銀行の前記コンピューティングデバイスから前記第２国側プロセッサに前記メッセージを送信するように構成されており、
   前記第２国側プロセッサは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、前記メッセージを受信し、前記メッセージ内のデータをチェックおよびバリデートし、前記メッセージを前記受取人側銀行の前記コンピューティングデバイスに送信するように構成されており、
   前記受取人側銀行の前記コンピューティングデバイスは、リアルタイムで個別に、かつ、電子決済トランザクションの前に、前記メッセージを受信し、受取人および前記受取人側銀行のデータと、前記受取人側銀行が入金する準備ができたことの確認とによって前記メッセージをエンリッチし、前記受取人側銀行が入エンリッチされた前記メッセージを前記第２国側プロセッサに送信するように構成されており、
   前記第１国側プロセッサは、リアルタイムで個別に、かつ、前記電子決済トランザクションの前に、
   前記仲介銀行の前記コンピューティングデバイスを介して、前記第２国側プロセッサから、エンリッチされた前記メッセージを受信し、
   前記メッセージを一意に特定する電子決済処理識別子を生成し、
   電子決済トランザクションについての事前承認された支払命令と、電子決済トランザクションの実行時に後続して使用するための電子決済処理識別子とを含むメッセージを、前記送金人側銀行のコンピューティングデバイスを介して、前記送金人側デバイスに送信するように構成されている、
   システム。
7. 前記送金人側銀行の前記コンピューティングデバイスは、前記受取人側銀行による入金準備の確認、第１通貨における送金額および換算後の第２通貨における送金額と、送金が承認されたことを示す電子決済処理識別子と、前記第１国側プロセッサへのメッセージの送信の確認と、を少なくとも含む、エンリッチされた前記メッセージに対する応答を前記送金人側デバイスから受信するように構成されており、
   前記第１国側プロセッサは、エンリッチされた前記メッセージを受信し、第１国側決済システムに、前記送金人側銀行の口座から資金を引き落とし、前記仲介銀行の口座に第１通貨において入金する要求を送信するように構成されており、
   前記第１国側決済システムは、前記要求を受信し、前記要求を満たし、前記第１国側プロセッサを介して要求充足の確認を前記送金人側銀行の前記コンピューティングデバイスおよび前記仲介銀行の前記コンピューティングデバイスに送信するように構成されており、
   前記仲介銀行の前記コンピューティングデバイスは、前記確認を受信し、前記第２国側プロセッサに送金リクエストを送信するように構成されており、
   前記第２国側プロセッサは、前記送金リクエストを受信し、前記仲介銀行の口座から第２通貨における資金を引き落とし、換算後に前記受取人側銀行の口座に第２通貨において入金する要求を第２国側決済システムに送信するように構成されており、
   前記第２国側決済システムは、前記要求を受信し、前記要求を満たし、要求充足の確認を前記仲介銀行の前記コンピューティングデバイスと前記受取人側銀行の前記コンピューティングデバイスとに送信するように構成されている、
   請求項６に記載のシステム。
8. 前記システムには、第１国側仲介銀行と第２国側仲介銀行とが含まれており、
   前記送金人側銀行の前記コンピューティングデバイスは、前記受取人側銀行による入金準備の確認と、第１通貨における送金額および換算後の第２通貨における送金額と、送金が承認されたことを示す電子決済処理識別子と、前記第１国側プロセッサへの前記メッセージの送信の確認と、を少なくとも含む、エンリッチされた前記メッセージに対する応答を、前記送金人側デバイスから受信するように構成されており、
   前記第１国側プロセッサは、エンリッチされた前記メッセージを受信し、送金人の口座から資金を引き落とし、前記第１国側仲介銀行の口座に第１通貨において入金する要求を送信するように構成されており、
   第１国側決済システムは、前記要求を受信し、前記要求を満たし、前記第１国側プロセッサを介して、前記送金人側銀行の前記コンピューティングデバイスと、前記第２国側仲介銀行の前記コンピューティングデバイスに接続された前記第１国側仲介銀行の前記コンピューティングデバイスとに、要求の充足の確認を送信し、前記第１国側仲介銀行の第１通貨における口座から前記第２国側仲介銀行の第２通貨における口座に送金するように構成されており、
   前記第２国側仲介銀行の前記コンピューティングデバイスは、前記第２国側プロセッサとの通信チャネルを有しており、送金の通知を受信し、前記第２国側仲介銀行の口座から資金を引き落とし、前記受取人側銀行の口座に第２通貨において入金する要求を第２国側決済システムに送信するように構成されており、
   前記第２国側決済システムは、前記要求を受信し、前記要求を満たし、前記第２国側プロセッサを介して要求充足の確認を前記仲介銀行の前記コンピューティングデバイスおよび前記受取人側銀行の前記コンピューティングデバイスに送信するように構成されている、
   請求項６に記載のシステム。
9. 資金を第１通貨から第２通貨へと両替するために、
   前記第２国側仲介銀行の口座が前記第１国側仲介銀行に開設されている、または、
   前記第２国側仲介銀行の口座が前記第１国側仲介銀行に開設されている、
   請求項８に記載のシステム。
10. 少なくとも１つの前記仲介銀行の前記コンピューティングデバイスは、前記送金人側銀行の前記コンピューティングデバイスおよび／または前記受取人側銀行の前記コンピューティングデバイスとの通信チャネルを有しており、前記送金人側銀行と少なくとも１つの前記仲介銀行との間で、または、少なくとも１つの前記仲介銀行と前記受取人側銀行との間で、資金を第１通貨から第２通貨へと両替するように構成されている、
    請求項６から８のいずれか１項に記載のシステム。
11. 少なくとも１つの決済システムは、各個別トランザクションの要求を満たすように構成されている、
    請求項７または８に記載のシステム。
12. 前記第１国側プロセッサおよび前記第２国側プロセッサは、受取人の口座にリンクされた少なくとも１つの受取人側識別子を、当該識別子によって前記受取人の口座を識別する能力を有するデータベースに格納するように構成されている、
    請求項６に記載のシステム。
13. 少なくとも１つのプロセッサは、電子決済処理識別子をメッセージに割り当て、リクエストに応じて前記メッセージのデータまたは前記データの一部を提供するために、前記電子決済処理識別子をデータベースに格納するように構成されている、
    請求項６に記載のシステム。
14. データの事前処理およびバリデートを、リアルタイムで個別に、かつ、電子決済トランザクションの前に行うための方法であって、
    前記方法は、送金人側デバイスにおいて開始され、メッセージの送信、検証、およびエンリッチを行うステップを含んでおり、
    前記方法の各ステップは、リアルタイムで個別に、かつ、電子決済トランザクションの前に実行され、
    前記方法では、
    前記送金人側デバイスは、少なくとも受取人側識別子と送金額とを含むメッセージを送信し、
    送金人側銀行のコンピューティングデバイスは、前記メッセージを受信し、前記送金人側銀行および送金人のデータを前記メッセージにエンリッチし、
    プロセッサは、前記メッセージを受信し、前記受取人側識別子を用いて受取人側銀行を特定し、前記メッセージを前記受取人側銀行に送信し、
    受取人側銀行のコンピューティングデバイスは、前記メッセージを受信し、受取人および前記受取人側銀行のデータを前記メッセージにエンリッチし、前記送金人側銀行の承認されたデータと、前記受取人側銀行の承認されたデータと、送金額と、電子決済処理識別子と、前記受取人側銀行が入金する準備ができたことの確認と、を少なくとも含む応答メッセージを、プロセッサに送信し、
    前記メッセージを一意に特定する電子決済処理識別子は、前記プロセッサによって生成され、
    前記送金人側銀行の前記コンピューティングデバイスは、電子決済トランザクションについての事前承認された支払命令と、電子決済トランザクションの実行時に後続して使用するために生成された電子決済処理識別子とを含むメッセージを、前記送金人側デバイスに送信する、
    方法。
15. 前記送金人側銀行の前記コンピューティングデバイスは、
    前記送金人側銀行の承認されたデータと、前記受取人側銀行の承認されたデータと、前記送金額と、前記電子決済処理識別子と、前記受取人側銀行が入金する準備ができたことの確認と、を少なくとも含むメッセージを受信し、
    送金人側銀行口座から資金を引き落とし、受取人側銀行口座に入金するための要求を生成して決済システムに送信するプロセッサに、前記メッセージを送信し、
    次いで、要求充足の確認が前記送金人側銀行の前記コンピューティングデバイスと前記受取人側銀行の前記コンピューティングデバイスとに送信される、
    請求項１４に記載の方法。
16. 決済システムは、各個別トランザクションの要求を満たしている、
    請求項１５に記載の方法。
17. 前記プロセッサは、受取人の少なくとも１つの社会的識別子によって前記受取人の口座を識別するためのデータベースに、前記受取人の前記社会的識別子を予め格納する、
    請求項１５に記載の方法。
18. 前記プロセッサは、電子決済処理識別子を前記メッセージに割り当て、リクエストに応じて前記メッセージのデータまたは前記データの一部を提供するために、前記電子決済処理識別子をデータベースに格納する、
    請求項１４に記載の方法。
19. データの事前処理およびバリデートを、リアルタイムで個別に、かつ、電子決済トランザクションの前に行うための方法であって、
    前記方法は、送金人側デバイスにおいて開始され、メッセージの送信、検証、およびエンリッチを行うステップを含んでおり、
    前記方法の各ステップは、リアルタイムで個別に、かつ、電子決済トランザクションの前に実行され、
    前記送金人側デバイスは、受取人側識別子と送金額とを少なくとも含むメッセージを送信し、
    送金人側銀行のコンピューティングデバイスは、前記メッセージを受信し、前記送金人側銀行のデータを前記メッセージにエンリッチし、
    第１国側プロセッサは、前記メッセージを受信し、前記受取人側識別子を使用して第２国に存在している受取人側銀行を特定し、為替レートを用いて送金額を第２通貨における送金額に換算するために、前記メッセージを少なくとも１つの仲介銀行に送信し、前記為替レートのデータを前記メッセージに格納し、
    仲介銀行のコンピューティングデバイスは、前記メッセージを第２国側プロセッサに送 し、
    次いで、前記メッセージは、受取人側銀行のコンピューティングデバイスに送信され、
    前記メッセージは、受取人および前記受取人側銀行のデータによってエンリッチされ、
    前記受取人側銀行は、入金する準備ができたことを確認し、前記送金人側銀行の承認されたデータと、前記受取人側銀行の承認されたデータと、前記送金額、電子決済処理識別子と、前記受取人側銀行が入金する準備ができたことの確認と、を少なくとも含む応答メッセージを、前記第２国側プロセッサに送信し、次いで少なくとも１つの仲介銀行の前記コンピューティングデバイスに送信し、次いで前記第１国側プロセッサに送信し、
    前記メッセージを一意に特定する電子決済処理識別子は、前記第１国側プロセッサによって生成され、
    前記送金人側銀行の前記コンピューティングデバイスは、電子決済トランザクションについての事前承認された支払命令と、電子決済トランザクションの実行時に後続して使用するために生成された電子決済処理識別子とを含むメッセージを、前記送金人側デバイスに送信する、
    方法。
20. 前記送金人側銀行の前記コンピューティングデバイスは、
    前記送金人側デバイスから、前記送金人側銀行の承認されたデータと、前記受取人側銀行の承認されたデータと、前記送金額と、前記電子決済処理識別子と、前記受取人側銀行の入金準備の確認と、を受信し、
    前記データと、前記受取人側銀行が入金する準備ができたことの確認と、少なくとも第１通貨における金額と換算後の第２通貨における金額とを含む支払い条件と、を含む送金要求を、前記第１国側プロセッサに送信し、
    次いで、前記第１国側プロセッサは、第１国側決済システムに前記要求を送信し、
    前記要求に基づいて、資金が送金人側口座から引き落とされ、前記仲介銀行の第１通貨における口座に入金され、
    次いで、前記仲介銀行は、第１通貨における仲介銀行口座から第２通貨における仲介銀行口座に送金し、エンリッチされた前記メッセージを前記第２国側プロセッサに送信し、
    第２通貨における仲介銀行口座から資金を引き落とし、第２通貨における受取人側銀行口座に入金する要求が生成され、前記要求が第２国側決済システムに送信され、
    要求充足の確認が前記仲介銀行の前記コンピューティングデバイスと前記受取人側銀行の前記コンピューティングデバイスとに送信される、
    請求項１９に記載の方法。
21. 前記送金人側銀行の前記コンピューティングデバイスは、
    前記送金人側デバイスから、前記送金人側銀行の承認されたデータと、前記受取人側銀行の承認されたデータと、前記送金額と、前記電子決済処理識別子と、前記受取人側銀行の入金準備の確認と、を受信し、
    前記データと、前記受取人側銀行が入金する準備ができたことの確認と、少なくとも第１通貨における金額と換算後の第２通貨における金額とを含む支払い条件を含む、送金についての要求が、前記第１国側プロセッサに送信され、
    次いで、前記第１国側プロセッサは、第１国側決済システムに前記要求を送信し、
    前記要求に基づき、資金が送金人側口座から資金が引き落とされ、第１国側仲介銀行の第１通貨における口座に入金され、
    次いで、前記第１国側仲介銀行のコンピューティングデバイスは、送金に関するメッセージを第２国側仲介銀行のコンピューティングデバイスに送信し、
    次いで、前記第２国側仲介銀行の前記コンピューティングデバイスから前記第２国側プロセッサに前記メッセージを前記第２国側プロセッサが送信され、
    前記第２国側仲介銀行の口座から資金を引き落とし、前記受取人側銀行の第２通貨における口座に入金するための要求が生成され、前記要求が第２国側決済システムに送信され、
    要求充足の確認が前記第２国側仲介銀行の前記コンピューティングデバイスと前記受取人側銀行の前記コンピューティングデバイスとに送信される、
    請求項１９に記載の方法。
22. 送金前、送金中、または送金後に、前記第１国側仲介銀行の口座から第２通貨における前記第２国側仲介銀行の口座に、資金が第１通貨において入金される、
    請求項２１に記載の方法。
23. 少なくとも１つの決済システムは、各個別トランザクションの要求を満たしている、
    請求項２０または２１に記載の方法。
24. 前記第１国側プロセッサまたは前記第２国側プロセッサは、前記受取人の少なくとも１つの社会的識別子によって前記受取人の口座を識別するためのデータベースに、前記受取人の前記社会的識別子を予め格納する、
    請求項２０または２１に記載の方法。
25. 少なくとも１つのプロセッサは、電子決済処理識別子を前記メッセージに割り当て、リクエストに応じて前記メッセージのデータまたは前記データの一部を提供するために、前記電子決済処理識別子をデータベースに格納する、
    請求項１９に記載の方法。
26. データの事前処理およびバリデートを、リアルタイムで個別に、かつ、電子決済トランザクションの前に行うための方法であって、
    前記方法は、送金人側デバイスにおいて開始され、メッセージの送信、検証、およびエンリッチを行うステップを含んでおり、
    前記方法の各ステップは、リアルタイムで個別に、かつ、電子決済トランザクションの前に実行され、
    前記送金人側デバイスは、受取人側識別子と送金額とを少なくとも含むメッセージを送信し、
    送金人側銀行のコンピューティングデバイスは、前記メッセージを受信し、前記送金人側銀行および送金人のデータを前記メッセージにエンリッチし、
    前記メッセージは、少なくとも１つの仲介銀行のコンピューティングデバイスによって受信され、
    為替レートを用いて、送金額が第２通貨における送金額に換算され、
    前記為替レートのデータが前記メッセージに格納され、
    次いで、前記メッセージは、前記仲介銀行の前記コンピューティングデバイスから受取人側銀行のコンピューティングデバイスに送信され、
    前記受取人側銀行の前記コンピューティングデバイスは、
    前記メッセージを受信し、受取人および前記受取人側銀行のデータを前記メッセージにエンリッチし、
    次いで、前記送金人側銀行の承認されたデータと、前記受取人側銀行の承認されたデータと、前記送金額と、前記受取人側銀行が入金する準備ができたことの確認を少なくとも含む応答メッセージを、少なくとも１つの仲介銀行の前記コンピューティングデバイスに送信し、
    前記メッセージを一意に特定する電子決済処理識別子は、前記仲介銀行の前記コンピューティングデバイスによって生成され、
    前記送金人側銀行の前記コンピューティングデバイスは、電子決済トランザクションについての事前承認された支払命令と、電子決済トランザクションの実行時に後続して使用するために生成された電子決済処理識別子とを含むメッセージを、前記送金人側デバイスに送信する、
    方法。