ロシアの国家支払いシステムは、既存のものよりも成功する可能性が高い

最近、ロシアで国民支払いシステムを構築することに関して疑問が生じました。



おそらく、VISA / MC Russiaに対するグローバルな競争相手を作ることは不可能でしょう。 代わりに、清算会社ではなく、VISA / MCのコピーを構築することができます。VISA/ MCのコピーは、ある時点で擬似銀行構造になりますが、各銀行がそのような清算会社の機能を実行するインフラストラクチャを構築します。



現在、政府と下院は、銀行が進歩の背後にあるという誤解から始まっており、この問題を解決するためには、国際的なVISA / MCシステムに類似したsuprabank構造を作成する必要があります。 これに同意することは不可能です。 記事の前半で、ロシアは、後の技術への「参入」により、これらの技術の低コストと「参入」を維持する「ブレーキ」なしでより高いレベルで「参入」できるという利点があることをすでに指摘しました。それらの前に。 これには多くの例があります。いわば、家計の類推をすることができます。いわば、「オープン」ライセンスのもとで、ウェブマスターが無料で利用できるようになった、「ペイオフ」するはずだった当時何百万ドルも費やされた開発用のデータベースです。



新しい技術的基盤では、銀行間の関係により、追加のsuprabank構造は必要ありません。



現在、私たちの会社は、ある連邦会社を別の会社に有利に売却するための大規模な取引を行っています。 この市場には少数のプレイヤーしかいないため、市場を示すことはありません。どの企業が問題になっているかはすぐに明らかになり、クライアントとの関係は、彼の同意なしに参加に関する情報を開示する必要はありません。 しかし、ここに私たちが今直面しているものがあります。 取引-すべてのデューデリジェンスおよびその他のトリックに加えて、管理LLCの株式の売却に関する単純な契約に帰着します。 ご存知のように、株式の所有権は、疎外のための取引の公証の時点で通過します(連邦法第21条「有限責任会社」の条項12)。 当初、投資家の代表者と信用状による決済の可能性について話し合いました。 しかし、実際の状況を計算すると、信用状なしでもできるという結論に達しました。



スキームは次のとおりです。 当事者は公証人で会合します(より正確には、公証人は自分でオフィスに到着します。50万ルーブルが「関税に正確に」あなたは乗車することができます)。 すべての文書を作成し、印刷し、購入者が契約書に署名します。 同時に、支払い注文に署名する権限を与えられた人は、クライアントの銀行を通じて支払いを送信します。 数分後、売り手は彼の銀行に電話をかけ、彼にサービスを提供している銀行のコルレス口座に資金が到着したかどうかを明確にします。 その後、売り手は契約に署名し、公証人がそれを証明します。



このスキームには非現実的なものはありません。 もちろん、私たちの状況では、すべてがこのように行われるためには、買い手が前日をオペレーターまたは銀行のマネージャーと合意する必要があります。そうすれば、買い手は彼からの支払いを待ってすぐに処理します。 売り手は、銀行口座の残高をすばやく確認できるように、前夜に銀行のオペレーターと合意する必要があります。 しかし、そのような大量になると、それほど難しくありません。



結果は何ですか? 支払いは文字通りオンラインモードで行われ、遅延は数分で計算され、人的要因のみによるものです。 少なくとも一定の限度まで、支払い処理への個人の参加を取り除く必要があります。これは、許容される支払いの上限として定義できます。 実際、銀行ではこれが現在起こっていることであり、個人の口座に大量を送り、サプライヤーの口座に少量を送ることで確認するのは簡単です。

このトランザクションの例では、支払い経路の遅延場所がはっきりと見えます。 私たちが最初に持っているのは、支払い文書の作成です(支払い注文に限定されません)。 明らかに、「カード」決済の場合、支払い文書は売り手が作成しなければなりません。 通常の場合、これは支払い要件になります(これはすべてのエネルギー供給会社がこれまで働いていた方法です)が、これらのポジションからこのドキュメントにアプローチする場合、支払い要件には3つのステップが必要です。



販売者による支払い要求の発行-支払者による承認-支払者銀行による販売者へのメッセージの送信。




一方、同じドキュメントを支払人の支払い注文と見なす場合、手順を2つのステップに短縮します。

支払人の「署名」を使用して支払注文を送信する-支払人の銀行に支払いを送信し、売り手にメッセージを送信する。




電子データ交換のコンテキストでは、すべてのステップで保存することが重要です。



そのため、売り手が「支援」する準備と充填の支払い注文。 支払人はとにかくこの文書に「署名」するため、これには違法なものはありません。



次に、支払人の識別情報があります。これには、何らかの物理媒体に保存されているさまざまな種類の電子データがあります。 クライアントが行う必要がある決済の状況では、これはクライアントバンクへのフラッシュドライブとPINコードです。「路上」での決済の場合は、銀行カードとパスワードですが、オプションが使い果たされているとは言えません。現在、多くの識別オプションがあります。



クライアント銀行による識別後、オペレーターは支払人から受け取った署名済みの支払い注文を確認し、銀行のコルレス口座(ロシア連邦中央銀行の各銀行に開かれている)から受取銀行のコルレス口座に送信する必要があります。



それだけです。支払いは「なくなった」ので、受取銀行はコルレス口座ですでに「見る」ことができます。



次に、受信者の銀行で同じ話が始まります。 オペレーターは、この支払いを確認し、受取人の口座、または銀行に口座がない場合は「明確化まで」特別口座に入金する必要があります。



銀行の顧客を識別する方法は現在も機能していますが、それらが普遍的であることを妨げるものは何もありません。 現在のアカウントの20桁の番号により、お客様の現在のアカウントを一意に識別できます。 最終的に、数値が十分でない場合、現在よりも少ないため、追加することができます。 銀行に送信する支払い注文には、TIN、KPP、決済口座、コルレス口座、BIC、シーケンス番号という番号があります。 さらに、パーティとその銀行の名前。 当然、支払いには常に2つの側面があるため、これに2を掛ける必要があります。 さらに、支払い自体の金額と根拠。 ご覧のとおり、これらの数字は十分であり、豊富であるため、TIN、PPC、コルレス口座、BIC、当事者名とその銀行名の代わりに、決済口座の単一のユニバーサル識別子が支払注文を支払人と受取人番号、支払金額、 2つの必要なデータ:支払いの基礎と支払人の署名。

このような作業スキームは、預金者の銀行の秘密を保証する権利を侵害しません。口座の内容に関するデータは銀行自体にのみ保存されるため、次のステップに進むこともできます。決済口座の現在のユニバーサル識別子のデータをオンラインで利用可能にします。 これにより、支払銀行は受取人の存在を自動的に確認し、誤った支払いを排除できます。誤った支払いには、現在別の口座47416が使用されています。

ユニバーサルアカウントIDの導入により、銀行への支払いの自動送信と配布が可能になります。



新規に構築された決済システムは次のようになります。

支払い注文の入力、その署名-受取人に通知を送信する支払銀行による承認。




明らかに、ここでは絶対にsuprabank構造は必要ありません。



受取人の銀行からの確認をこのチェーンに追加できますが、これは追加のリンクです。ロシア連邦中央銀行のレベルで問題を解決できるため、支払人の銀行は支払いが送金されるまで受取人に通知を送信できません。これはソフトウェアで簡単に解決できます。 ただし、受益者の銀行の確認も特に難しくはありません。



残る質問は1つだけです。オペレーターの参加がない支払い額はいくらになるのでしょうか。 バーは異なるように設定することができ、誤った支払いのリスクに保険をかけることができます。 おそらく100,000から200,000ルーブルになりますが、現在はおそらく異なる金額があります。 最終的に、エラーのリスクは、支払いの「手動」処理に残ります。



支払いシステムがそのようなベースで構築されている場合、決済は現金決済と同じように簡単に行うことができます。たとえば、不動産の決済時には、当事者はメモをチェックする長い手続きを強いられますが、そのコストは異なる銀行にあります法案ごとに1ルーブル。 お金の再集計は、現金を扱う銀行では別のサービスです。



そのような決済スキームを実施するために中央銀行は何ができますか?



実際、すべては銀行間レベルでほぼ準備ができており、銀行内で行われているプロセスに対処するためだけに残っています。 ここではすべてが非常に軽視されていることを認めなければなりません。 銀行の銀行顧客に出会った人は、このことを直接知っています。 銀行プログラマーのInternet Explorerに対する病理学的なコミットメントと、かなり古いバージョンを考えると、原則として、オンラインクライアントはましです。



このような状況では、中央銀行は、このプロセスから取引担当者を除いて、銀行内での支払いを識別および実行するための統一された標準を導入することを全員に義務付ける必要があります。 これはそれ自体は難しくありません。なぜなら、多くの方法で手順がすでに正式にされており、もちろん実際には「手動」の支払い処理が実行されていないからです。 おそらく、銀行内プログラムを統一するか、銀行自体が開発することができますが、中央銀行の要件に従ってください(たとえば、支払い処理は平均的なプロセッサー、フォーマットで5μs以内です)。



さらに難しいのは、ユーザーとリーダーの識別に関する問題です。 ただし、この分野では多くの開発が行われているため、オプションを決定するだけで、誰もがそれを使用することを強いる意思があります。 安全性、コスト、信頼性、エネルギーの独立性、およびその他の要件に基づいてオプションを選択する必要があります。これらすべてが最適性に影響を与える可能性がありますが、一般的に選択できるものがあり、十分な専門家がいます。 既存の設備に基づいて新しいシステムを構築することが可能です。



もちろん、記載されている決済システムには、ロシアの銀行システムの一部ではない銀行との決済に関して問題があります。 この問題は、多くの外国銀行がロシアに駐在員事務所を持ち、当社の銀行が外国銀行のコルレス口座を持っているという事実によって緩和されています。 しかし、一般的には問題は残っていますが、州間レベルまたは銀行間協定のレベルで解決できます。 提案されたスキームは、銀行にとって有益であり、消費者にとって有益です。 銀行は国際決済システムの形で独占から免除されており、消費者はこれらの決済システムにサービスを請求する3〜3.5%を支払いません。



要約すると、新しい決済システムの構築は、VISA / MCのような時代遅れで高価なソリューションではなく、より有望で費用のかからない方法に基づいて、さらにロシアの実際の既存の銀行システムに焦点を合わせて実施する必要があることに注意できます。



All Articles