カード、口座、2つの残高

Raiffeisenbankのデビットカード所有者が知っているように、このカードはアカウントへのアクセスツールにすぎません。独自の残高はなく、クライアントの現在のアカウントで利用可能な資金のみが利用できます。 この記事では、銀行のカードと口座で単一の残高を使用できるようにする技術的ソリューションのアーキテクチャについて説明します。 また、プロジェクトがどのように編成されたかを学ぶことで、このアーキテクチャを実装できました。



まず、「アカウントからカードへ」と「カード自体で」のスキームがどのように異なるかを例で示しましょう。 ロシア連邦の銀行システムを介して電信送金を受け取ったとします-子どもの出産に対する州からの補償。 「カードからアカウント」スキームでは、この金額は、振替が銀行口座に入金された時点で、カードでの支出取引に利用可能になります。 「単独のカード」スキームでは、一定の金額を通常の口座からカード口座に送金する必要があり、その後、資金はカードで使うことができます。



このように一見基本的で論理的な機能は、かなり複雑な技術的ソリューションによって提供されますが、これはすべての銀行でうまく実装されるにはほど遠いです。 たとえば、2014年まで、当社の銀行では、デビットカードの残高は口座残高とは別個に存在していました：処理中のカード、ABSの近くの口座。 天びんは、営業日の朝に同期されました。 言うまでもなく、このようなスキームは顧客に問題を引き起こしました：ある人が預金を途中で解約した場合、彼は明日だけカードでお金を使う/引き出すことができます。 そして、今日が土曜日の場合、「明日」は月曜日に変わりました。 当時、banki.ruの苦情のかなりの3分の1がこのトピックに何らかの形で関連していた。 銀行内では、この実装も困難につながりました。口座での経費処理では、クライアントがカードに同じお金を使ったかどうかを確認する必要がありました。 その結果、ほとんどのシステムはソフトウェアPOSターミナルエミュレーターを使用しました。このエミュレーターを使用して、カードの残高がチェックされ、処理中に特別なブロッキングが行われました。 このチェックはすべての場合に正しく機能するわけではなく、多くの場合、オペレーターによる手動の介入が必要でした。 たとえば、カードは一時的にブロックされ、100ルーブルがあり、クライアントはアカウントから100を引き出し、POS端末エミュレーターはそのようなロックに対してエラーを表示し、金額はブロックされません。 この問題を無視した場合、アカウントでアカウントトランザクションを行った後、クライアントはカードのロックを解除し、さらに100ルーブルを引き出します。



これは、以前のアーキテクチャを使用する際に銀行が直面した問題の完全なリストではありません。 ある時点で、このアーキテクチャが銀行のサービスの開発を妨げているという認識に至り、「カードからアカウント」の技術的な実装を作り直すことにしました。



答えるべき重要な質問は次のとおりでした：利用可能な残高の現在の価値はどのシステムで生きますか？ 通常、銀行にはこの役割の2つの候補があります-処理システムとABS。 伝統的に、処理では、カードの残高は「カード自体」のパラダイムに存在し、ABSでは経常収支に存在します。 また、従来、これらのシステムはどちらも、主要なサプライヤーからカスタマイズされたボックスソリューションを購入しており、カスタマイズ機能は限られていました。 3つ目の方法、つまり、手頃な価格のバランスで作業するための別のシステムを作成することにしました。 いくつかの要因がこの決定を促しました。



第一に、「銀行口座」銀行商品の大部分（現金、銀行間支払い、保険など）は、ABS内に存在しません。 これらは、既製の会計エントリをABSにダウンロードする非常に独立したシステムです。



第二に、これらのシステムのサプライヤーによる処理とABSの改善を最小限にしたかった。



第三に、ABSメカニズム自体は、これらの外部システムによるアカウントとの経費トランザクションのバランスを制御するために使用されませんでした。



歴史的に、銀行の営業日は、ABSの営業日の開始時の残高、ABSですでに確認された取引/転記、および一部の取引システムの中間取引データに基づいて特別なシステムによって現在の口座残高値が計算されるように調整されていました） しかし、ABS内部で開始される操作のバランス制御についてはどうでしょうか？ 結局のところ、彼女はバランスをチェックするために3番目のシステムに頼ることはできませんか？！ クレジット商品（支払いスケジュールでのスケジュールされた償却、遅延支払いの処理）の場合、ABSは1日の終わりに残高を使用します。プロセスでは、3番目のトランザクションシステムからのすべての中間の動きが営業日の終わりまでにABSに記録されます。 トランザクション商品（預け入れ、外国為替支払いの送信など）の場合、残高は手動（ABSで操作を手動で入力する場合）またはAPIを介したすべてのチェック後にABSで操作を形成する外部システムで制御されます。



経験を積んだ目では、このスキームにいくつかの欠点があります。 これは、ABS以外の現在の残高の計算の実装であり、第3システムのデータの残高の計算における会計処理です（ABSとは別のDBMSに保存されます）。 短所を長所に変えようとしました。 利用可能な口座残高の現在の値がABSの外部で計算されるという事実には、いくつかの利点があります。 銀行は、その裁量で（ABSを変更せずに）残高計算アルゴリズムを変更する場合があります。ABSで1日を締めるプロセスで残高を計算する方法を何らかの方法で学習できます。 この瞬間について詳しく説明します。 私たちのABSは前世紀のコンセプトに基づいています：それは数時間続く日を閉じるプロセスを提供し、その間ABSで何もすることができません-トランザクションを入力せず、データを監視しません。 しかし、バランスがABSの外側と見なされる場合、この問題は回避できます！







そのため、利用可能なバランスの真実のソースとなるターゲットシステムを決定しました。ABSでも処理でも、新しいシステムではありません。 それをコード文字NIと呼びましょう。 銀行システムの上記の機能に基づいて、NIシステムを正しく実装するには、次のアクションを実行する必要があります。

• 残高を計算する際にトランザクションシステムのデータを分析することを拒否します（このような3つのシステム-現金、ルーブルの支払い、および法人の変換に言及しました）。 これは、サードパーティのDBMSにアクセスしないように、カード認証の信頼できる迅速な作業に必要です。
  
  
• バランスの計算に現在の専用システムを使用しているすべてのシステムをNIに切り替えます。 または、古いシステムをNIに接続します。これは簡単です。 これが最終的に選択したものです。
• NIにABSの運用日を締めるプロセスで何らかの形で作業する方法を教えること。
• NIをカード処理に統合します。
• これらすべての変更がインターネットバンキングにどのように影響するかをご覧ください。

アカウントの残高を計算するときの3番目のシステムのデータの拒否

どのように機能しましたか？ ABSの1日の初めにクライアントの口座で残高が100ルーブルだったとします。 クライアントは午前10時にレジで50ルーブルを引き出しました。 キャッシュレジスタシステムにはレジで確認された動作がありますが、その配線はまだABSで作成されていません（1世紀ではなく、ABSを1つずつではなく、大きな束で受け入れるのが大好きであることを思い出してください）。 現金システムは、その計画に従って、単一のバンドルで正午にABSに転記することで、この操作および他の確認済み操作をアンロードする予定です。 50ルーブルが口座残高になくなったことを考慮する方法は？ 2000年代初頭、銀行はこのための「エレガントな」ソリューションを見つけました。残高計算システムは現金システムのベースへの接続を開き、キャッシャーによって確認されたがまだABSにアップロードされていないすべての操作を選択します。 そして、3つの異なるシステムで。



明らかに、利用可能な口座残高の「瞬間」操作の会計処理は、後でトランザクションのバンドルによってABSにアップロードされ、かなり典型的なタスクです。 過去10年半のオンラインバンキング商品全体がこの方向に向けられてきました。 似たような新しいシステムが登場すると、バランス計算システムをそれぞれに接続する必要があります。 これは、開発の観点からは行き詰まりです。 これは、システムが3つしかない場合に実現し、それらに対処することさえ困難でした。



確認されたがまだABSにアップロードされていないすべてのアカウントの動きの単一のリポジトリを作成するとき、ソリューションはより正確に思えました。 そして、利用可能な残高での操作をリアルタイムで考慮する必要があるすべてのシステムは、利用可能な残高の現在の値の計算とアカウントの動きの作成による変更の両方を可能にするAPIのセットを介してこのリポジトリに接続する必要があります。 彼らは新しいシステムをNIと呼ぶことにしたので、そのAPIは「NI API」と呼ばれます。 同時に、利用可能な残高を計算する古いシステムは、速度と信頼性の目的で、この新しいNIストレージとストレージ自体を調べることを学ぶ必要があり、ABSが存在する同じシステムに配置することにしました。 私たちの場合、これはIBM iプラットフォームです。



アカウント内のすべての動きを条件付きで2つのタイプに分けることにしました。保有と転記です。 保留は、実際に引き落とされるという事実ではない、顧客アカウントの特定の金額のロックです。 保留には有効期間を設定することも、無制限にすることもできます。 このタイプの動きは、カードの承認、さまざまな監督当局の決定による金額の逮捕などに使用する予定でした。 転記は、実際に発生したが、まだABSに達していないアカウントの動きです。



アカウントの動きを作成するためのオプションをAPIに追加することも賢明です。このオプションでは、利用可能な残高が正常にチェックされた場合にのみ動きが作成されます。 外部システムは、「クライアントの残高に現在の残高が許す場合、100ルーブルのアカウントトランザクションを作成します」と言っています。



この例で、レジシステムがNI APIとどのように機能するかを想像してください。 クライアントはレジで朝の10時に50ルーブルを引き出します。 現金システムは、リクエストでNI APIを呼び出します。「クライアントの残高に現在の残高が許す場合、50ルーブルのアカウントトランザクションを作成します。」 NIは残高を計算し、操作を完了できるようにします。NIは中間保管庫に50ルーブルの動きを作成し、現金システムに答えます：「すべてが順調です、配ってください。」 クライアントのアカウントの残高が50ルーブル未満の場合、NIは「物事が悪い、残高の現在価値は40ルーブル」と答えます。



12時です。キャッシュシステムが完了したトランザクションのバンドルをアンロードしてABSに転記する時が来ました。 理論的には、荷を下ろす操作の際に、彼女はこれらの動きがすでにABSに達していることをNI APIに通知する必要があり、動きの中間ストレージからそれらを削除する時が来ます。 そして、ここから困難が始まります。 ABSでトランザクションのバンドルをアンロードするプロセスのロジックに従って、バンドル全体に対して1つのコミットが行われます。 そのため、これらの動きをバンドル内のNIリポジトリから1回のコミットで削除する必要もあります。 投稿のバンドルは非常に大きくなる可能性があり、コミット間の時間間隔は非常に大きくなる可能性があります（最大数十秒ですが、私たちにとってこれは非常に長いです）。 技術的な障害は、ABSでのパケットコミットが成功した場合にも可能ですが、何らかの理由でNI APIで-いいえ。 このため、お客様の口座の現在の残高の値が正しくないというリスクがありますが、これは銀行では不適切です。



幸いなことに、NIシステムの設計段階でこれらのリスクを特定しました。 それらを平準化するために、彼らはNIの機能をABSに「引き伸ばす」ことにしました。 投稿作成APIで、外部システムがこれらの投稿を結合する投稿のバンドルの識別子を含む必須フィールドが追加されました。 また、別の関数「ABSへの投稿のパケットを書き込む」が追加されました。NI自身がその投稿をABSに記録し、ストレージとABSに1回コミットしました。 これは、NIデータベースとABSデータベースが実際には1つのDBMSに配置されていたという事実によって大いに助けられました。 したがって、12時の時点で、レジシステムは単にNI APIに次のように言いました。「ABSでNI投稿のバンドルをアンロードし、発生した問題を通知してください。」



問題は非常にまれですが、発生しています。 たとえば、口座の費用の動きをNIに追加してからこの動きをABSにアップロードして口座を逮捕するまでに銀行に執行官が来たとき。 このような場合、レジシステムは問題のある操作に関する情報をユーザーに提供し、状況を手動で処理する必要がありました。



いくつかの論理的にグループ化されたAPIを外部システムに提供するNI APIが開発されました。

• アカウントに関する情報（残高、ステータスなど）を取得します。
• パックの操作（ABSでの作成、削除、アンロード）。
• バンドル内の個々の配線を処理します。
• 保留を操作します。

技術的には、APIはプログラミング言語で記述された一連のプログラムで、SQLを使用したフリーフォーマットILE RPGです。 IBM Iプラットフォームの外部でAPIを使用するために、プログラムはDB2 for iに基づくストアドプロシージャでラップされ、外部システムは標準ODBC、JDBCなどを使用して動作できます。 また、NI APIへのアクセスは、企業統合バスESBから実装されました。ESBは、ODBC / JDBCを介してAPIにもアクセスしました。

一部のシステムをNIに切り替える

NIアカウントの新しい中間移動レポジトリと連携できるように、利用可能な残高を計算する以前のシステムを改良することを決めたため、銀行のすべてのITシステムを改良する必要はありませんでした。 ただし、前述の3つのシステム（現金、ルーブルの支払い、法人の変換）をやり直して、中間の動きにNI APIの使用を開始し、残高の計算時にこれらのシステムのトランザクションデータを使用しないようにする必要がありました。 実際、各システムでオペレーションライフサイクルを処理するためのメインロジックをやり直す必要があったため、これはかなり複雑な改良であることが判明しました。 ルーブル支払いシステムの場合、システムの内部アーキテクチャをやり直さなければならず、2リンクから3リンクに移行しました。 これは、アプリケーションサーバーでNI APIを操作するためのロジックを集中化するために必要でした。



しかし、この段階での主な困難は、技術的および建築的だけでなく、ビジネスの側面にも関連していました。 リストされたシステムは、改善の点で顧客から非常に要求されています。バックログには、製品、プロセスの開発、最適化に関する多くのアイデアが常にあります。 このような大規模な改善を、ビジネスの観点から具体的なものなしに実行する必要性は、熱意なく顧客によって認識されていました。 変更の本質は、利用可能な残高を計算するためのシステムがこれらのシステムのベースに移動するのをやめることであり、APIを介して中央のNIシステムにアカウントの動きを通知することでした。 ビジネスでは、これは実質的に価値がありません。



この状況から抜け出す方法を見つけ、ビジネスを私たちの側に説得するために、一連の成功した状況が私たちを助けました。 ちょうどそのころ、現金システムにプラスチックカードのオフバランス会計のモジュールが導入されました。 多くのカードがあり、それらの移動プロセスは非常に複雑です。これは、オフバランス口座での多数のトランザクションを意味します。 ABSの外部システムから投稿を生成する古いメカニズムには重大な欠陥があります。ABSで作成された投稿パッケージは、ABS自体のユーザーインターフェイスを使用して手動で受け入れなければなりません。 さらに、これは、限られた人のサークルにのみ発行される特別な権限を持つユーザーが実行できます。 また、前述の不均衡プロジェクトでは、これらのパッケージを誰が受け入れ、誰にどのような権利を与えるべきか、与えないべきかについて、さまざまな部門間で激しい議論がありました。 解決策を提案しました。NIAPIで、すでに受け入れられている形式のABSに投稿パッケージを作成できるオプションを作成します。 もちろん、このためには、モジュール全体を新しいAPIに転送する必要があります。 誰もがこのアイデアを本当に気に入りました。私たちはそれをやり直すというゴーサインを与えられました。



すでに受け入れられている投稿パッケージを作成するメカニズムの実装は、技術的には非常に難しいが、興味深いタスクであることが証明されています。 通常のABSプログラムの呼び出しスタックを分析して、受け入れを通知し、DBMSトランザクションログでデータの操作を追跡しました。 その結果、ABSをだまして受け入れられる投稿を作成することを学びました。 オフバランスシートのキャッシュモジュールはNI APIで起動され、トランザクションはオペレーターに受け入れられずにABSに流れ込み、NIに切り替えるためにビジネスを刺激する方法を理解しました。 その秘密はシンプルであることが判明しました。移行中にビジネスを提供して、プロセスを簡素化するか、他の方法で製品を改善する追加機能を提供する必要があります。 そして、マップは私たちに行きました...



その結果、NIはブロックされたアカウントへの投稿を作成する機能で大きくなりました（以前のプロセスでは、裁判所命令による償却などに関連し、アカウントは一時的に手動でブロックが解除されました）。 これにより、ビジネスは機能を移行しながらパンを手に入れ、プロセスを大幅に合理化できました。 それで、現金デスクとルーブルの支払い-完了、企業顧客の通貨交換業務が残った。



このシステムでは、物事はうまくいきませんでした。 その中で行われた操作はほとんどなく、機能の開発の必要はなく、最適化は大きな利点を約束しませんでした。 その結果、改善の必要性をパートナーに納得させることができず、彼女に手を振った。 これまで、法人顧客アカウントの残高を計算するとき、DBMSとの接続が開かれていました。 しかし、個人のアカウントによると、残高を計算するためのすべてのデータは単一のIBM i DBMSに集中しており、計算は迅速に（アカウントあたり約5ミリ秒）確実に行われたため、これは私たちの主な目標を達成したため、私たちを混乱させませんでした。

NIにトレーディング日の締め切りの過程で働くように教える

よく見ると、このタスクは驚くほど簡単でした。 終業中のABSは口座の動きを受け入れることができなかったため、銀行は夜に凍結しただけです。 アカウント取引は行われませんでした。 したがって、NIでの変更は、ABS自体を除く他のシステムと同期する必要はありませんでした。 その結果、特別なNI制御プログラムへの呼び出しを、取引日の終業プロセスの最初（昼→夜）と最後（夜→昼）に挿入することにより、ABSを少し改善しました。



「昼→夜」プログラムは、残高の計算に必要なABSテーブルを同じDBMSの別のライブラリに単純にコピーしました。 プリミティブなINSERT SELECTコンストラクトが使用されました。 すべてのコピーには約20分かかりました。 コピーが完了した後、NIは、ABSテーブルではなくコピーに移動する必要があることを理解しました。



「夜間->日」プログラムは即座に機能し、NIをメインのABSベースで動作するように切り替えるだけでした。



このソリューションにより、サービスを中断することなく、1日のフェーズを切り替えることができました。 外部システムがABS日の終わりに完了したかったすべてのアカウントの動きは、NIに蓄積されました。 さらに、ABSの日が開いた後、外部システムはNI APIを介してABSに投稿をアップロードするコマンドを提供する必要がありました。 これは外部システムにとってあまり便利ではないため、STPメカニズム（ストレートスループロセッシングから）が後で作成されました。外部システムはNIで配線を作成するだけで、それ自体がパッケージにグループ化され、ABSにアップロードされます。利用できます。



昼夜の計画には恵みがないわけではありません。 標準のIBM iコンテキストエンジン（ライブラリのリスト）を使用しました。 2つのライブラリが作成されました-昼と夜。 彼らはそれぞれ、ABSテーブルの昼と夜のコピーのエイリアスを作成しました。 各テーブルとその夜間コピーに対して、エイリアス名が一致します。 すべてのSQL式は、ABSデータにアクセスするためにエイリアスのみを使用していました。



各呼び出しを処理する前に、NI APIはIBM iシステムの特別なデータ領域オブジェクト（非常に高速な読み取り/書き込み）を調べて、このプロセスの最後のAPI呼び出しからモードが変更されたかどうかを理解します。 ご想像のとおり、データエリアのモードは、プログラムを昼から夜、夜から夜に変更します。 モードが変更された場合、プログラムは単にプロセスライブラリのリストにあるライブラリをエイリアスに置き換えます;これは非常に高速な操作です。



その結果、すべてのNI APIクライアントシステムは残高を計算し、ABSの稼働日を実際に心配することなく、24時間中断なく操作を行うことができました。 私たちにとってそれは革命でした。



これについては、夜間/昼間の移行のロジックの開発を停止しませんでした。 SQLを使用してテーブルをコピーする20分間は、休息を与えませんでした。 レプリケーションスキームが考案され、高可用性MIMIXソリューションを使用して実装されました。 アイデアは、ABSの日が閉じたときではなく、日が開いたときに夜間コピーが作成されるというものです。 日中、ほぼリアルタイムモードのこのコピーは、ABSデータと同期されます。 そして、運命の一瞬に備えて、プライマリとバックアップの2つのIBM iシステムで一度にレプリケーションを行います。







現時点では、昼から夜に行ってほぼ瞬時に戻り、サービスは一瞬中断されません。

銀行カード処理との統合

ご存知のように、銀行カード取引のライフサイクルは、承認と清算の2つの主要な段階で構成されています。 ただし、場合によっては、許可が許可されない場合があります。



利用可能な残高の観点から、承認中にクライアントのアカウントの利用可能な残高を確認し、「保留」で取引金額をブロックし、その決定について支払いシステムに返信する必要があります。 クライアントに操作に関する通知を送信することもお勧めしますが、これについてはインターネットバンキングの章で検討します。 クリアするときは、認証中に以前に設定された保留を見つけて削除し、クライアントのアカウントへの投稿を作成する必要があります。



プロジェクトの開始時に、処理システムは、承認中に外部システムへの利用可能な残高の検証を申請することができました。 Impexにはカードからアカウントへの製品があったため、この機能はImpexbankと統合されたときに以前に作成されました。 操作の承認プロセスでは、純粋なカードチェック（暗号化、PINコードなど）が完了した後、承認システムはISO-8583メッセージを外部システムに送信して財務承認を求め、一定の秒数の間応答を待ちます。 このプロトコルを使用して処理システムと通信できる特別なNIモジュールを作成する必要がありました。 メッセージを受信し、フィールドに解析し、NI APIを呼び出して応答を作成します。 かなり単純なタスクですが、一見しただけです。



最初の困難は、銀行カードを使用してクライアントのアカウントを補充するオンライン操作で私たちを待っていました。 これらは、ATMへの支払いとカードからカードへの着信転送です。 これらの操作のロジックによると、承認と清算は異なる銀行日に行われます。 口座の残高がゼロのクライアントが、4月1日の10:00に第三者銀行から送金を受け取ったとします。 10:05に、クライアントはこれらの資金をローンの早期返済に許可します。 この操作のクリアは4月2日に届きます。 4月1日（承認中）にアカウントの補充を伴う会計転記を行わず、単に「プラスの保留」で残高を上げる場合、アカウントのローンの返済後、マイナスの残高があります。 銀行会計では、技術的な当座貸越はあらゆる方法で回避され、補充方法として承認取引に転記するという唯一の方法があります。



最初の複雑さから、2番目-為替レートの違いが続きます。 外国銀行からの送金の場合、通貨の変動により、承認および清算中の金額が異なる場合があります。 実際の例を使用して説明します。 6月11日、クライアントはベラルーシの銀行からカード振替を受け取りました。振替額は15.00ベラルーシルーブルです。 銀行は、カード取引のために世界のすべての通貨への換算レートを物理的にサポートすることができません。ルーブル、ドル、ユーロの3つの通貨でレートを実行します。 承認支払システムは、発行者の通貨への独自のレートで振替金額を再計算します。この場合、ロシアルーブルで、金額は455.50でした。 クライアントのアカウントはルーブルで開かれているため、到着時に455.50ルーブルを費やしました。 この瞬間から、クライアントは必要に応じてこのお金を管理できます。



6月14日に支払いシステムからの清算が行われ、この操作のために7.16ユーロが銀行に振り込まれました。 会計の観点から見ると、私たちは時間をかけて分散操作を行ったことがわかりました。455.50ルーブルで7.16ユーロを買いました。 , . 14 , 7,16 445,35 . , 10,15 . , , . . , , . . , . — « ». , , .



. . , , . , SMS , . , . , , . SMS, .



, . - , . , , - NI API ( NI - ). — NI , . . :

• API .
• «» API , , .

, NI API — . , , - . , , . - NI API . , . NI , , , , (, ). -, . NI .

-

- : / . - . , . . ? - !



. ! - , , . . , - . ; , .







NI - . , . - NI API . . , - - .



SMS- . NI SMS - . - . NI IBM WebSphere MQ. NI , : , , . , , . SMS- , . , , , SMS , .



- , .

おわりに

, , . . «Business 24x7», /. - .



, , , . !

いくつかの乾燥した統計：

• 銀行の取引の約70％はNIを通じて行われます。
• 残高要求のAPIは1日平均500万回呼び出され、ピーク日には8に達します。すべての要求の約半分はRBS（顧客への情報の表示）によって処理されます。