外貨両替：オフラインオフラインのレートを修正します。 VTB24の経験

外貨両替は退屈で標準的なプロセスであり、何らかの理由で誰もが通過します。 技術的には、特別なことはすでに何もないようです。 VTB24はそうは思わない-銀行として、私たちは表面上にないいくつかの通貨交換の問題を知っている。あなたは突然、そして最も不適当な瞬間に遭遇するかもしれない。 そして、ITを使用してそれらを解決しました。 どの問題とどのように正確に解決される-カットの下で読んでください。







VTB24は新しい通貨交換サービスを考案しました-オンラインで為替レートを固定したので、オフィスに来て通貨を交換できます。 レートは、銀行のWebサイトまたはFacebookメッセンジャーのチャットボットで修正できます。 このサービスにより、顧客は注文日をカウントせずに2営業日分の通貨為替レートを修正し、市場レートが変化した場合でも現金通貨交換を行うことができます。



このサービスは、ロシアの銀行のカードをお持ちのお客様が、オンラインで年中無休でレートを固定して現金通貨の売買を行うことができます。

どうやってこのアイデアに到達したのですか

アイデアの形成と新しいサービスの作成には、いくつかの前提条件がありました。

これらは、ホリデーシーズン中に最も一般的な質問です。「通貨はどこで変更できますか？ 最高のコースはどこですか？ 利益を上げる方法は？」、為替レートの動的な変化、および顧客側の確実性の向上。



オンラインでの購入が増えているため、現金交換などの保守的な市場であっても、銀行サービスも変化しています。 イノベーションは、通常そうであるように、顧客のニーズから生まれます。



クライアントが現金を交換する必要があるとき、彼は通常銀行の両替所に行きますが、銀行が十分な量の通貨を持っていることを誰も確認しません-特にそれが大きい場合。 最良の場合、上級クライアントは銀行に電話して通貨の利用可能性を確認しようとします。 同時に、誰もが銀行がより早く来た別のクライアントに通貨を売ったり、多くの銀行にとって優先事項である預金者に渡したりできることを理解しています。 さらに、銀行はいつでもコースを変更できます-時々、それは1日5〜6回発生します。 これはすべて、消費者に不快感をもたらします。



したがって、リアルタイムでレートを修正し、同時に現金通貨を交換できるオンラインストアのアイデアを実装することが決定されました。



したがって、新しいサービスは2つの問題を解決します。

1. クライアントにレートをオンラインで修正し、後で都合の良いときに現金交換のための取引金額を提示する機会を与えます。
2. 銀行の現金窓口での交換に必要な通貨またはルーブルの利用可能性をクライアントに保証します。

誰かがインターネット銀行で通貨を交換することは可能だと言うでしょうが、取引は非現金化され、補償額は事前に口座にある必要があることを考慮に入れなければなりません。 多くの人々は現金を扱うことを好み、銀行の選択を口座とインターネットバンキングがある人に限定しません。



このサービスをサイトに実装するだけでなく、人気のあるソーシャルネットワーク（ Facebookのチャットボットなど）で利用できるようにすることも決定しました 。



VTB24は、支店でこれを実装した最初の銀行の1つであり、クライアントにとっては、国家参加の有名な銀行ブランドとのやり取りが便利で信頼性があります。



技術的には、プロセスは次のようになります。 ユーザーは、サイトobmen.vtb24.ruまたはFacebookのチャットボットにアクセスし、為替レートを確認します。為替レートは2日間修正できます。



次に、彼は自分のデータを入力します-姓、名、ミドルネーム、連絡先の電話番号、必要に応じて、電子メール。 チャットボットは、ユーザーが削除を要求するまで、これらのパラメーターを新しい注文用に保存します。 通貨金額を入力した後、ボットはチャットで通貨を交換する必要がある期間と、取引の瞬間までの交換の保証としてクライアントのアカウントに予約されている金額（取引金額の10％）を書き込みます-拒否または遅延の場合、銀行はそれを保持します インターネットでホテルを予約したり車を借りたりする旅行者が同様の予約を行い、カードに保証金として資金を提供します。



注文を確認した後、クライアントは支払いページに進み、カードの詳細を入力します。予約操作が成功すると、次のページに注文の確認（番号とパラメーター）が表示されます。 注文の領収書は電子メールで送信されます。













コースの更新の観点から、ボットとサイトは銀行のフロントオフィスシステムに接続されており、リアルタイムの通貨相場を提供します（リアルタイムモード-取引所からのティック、つまり1秒間に1回）。

これにどのように対処しましたか？

サイトとチャットボットを開発するために、EPAMとInspiredGamesからパートナーを集め、

プロジェクトの技術的特徴についてコメントするよう依頼しました。



Word InspiredGames：



「当社のスタジオは、すべての主要なメッセンジャーにボットを販売して、通貨交換業務の分野で銀行サービスを提供するタスクを引き受けました。 一見複雑に見えますが、ほとんど普通のオンラインストアです。



ただし：

• 銀行は非常に動的なレートを提供します。 営業時間中、それらは取引所のリアルタイムの見積もりを反映し、夜間（そしてもちろん、24時間体制のサービス）も正しいです。 銀行は、独自のサービスを使用してこれらの見積もりをボットエンジンに転送します。
  
  
  
  
• 支払いシステムの1つのWebページのみに移行するボットからのクレジットカードによる直接の準備と支払い（より正確には、資金のブロック）が実装されました（もちろん、インスタントメッセンジャーで新しい支払いオプションに取り組んでいます）。

同時に、ボットはインターフェイスですが、通常はバックエンド部分に関連付けられている機能も実装します（銀行からの現在のレート、権限を与えられた従業員のAWP、注文に関するデータの計算、支払いシステムとのトランザクションアクション、リマインダー、監査、上記） ...）。



問題は正常に解決され、サービスは機能しています。適用したいくつかのアプローチについてお話ししたいと思います。 もちろん、これらのアプローチと意見を検証することを嬉しく思います。



だから、まず第一に、フレームワークまたはコンストラクタを使用するかどうかの選択はありましたか？ Microsoft Bot Framework-すばらしいですが、Viberへのコネクタはなく、VKontakteへのコネクタもありません。 他のコンストラクター（少なくとも見つかったもの）には、必要な柔軟性がありませんでした。 したがって、私たちはすべて自分でやることに決めました。 インフラストラクチャソリューションについては、RESTful Web API、IIS、および便宜上、MS SQLをDBMS（すべてのビュー、共有、いくつかのストアドプロシージャとトリガーを含む）として使用することをお勧めします。



これはすべて明らかです。 しかし、最初から明らかではなかった2つのことがあり、出会ったボットには見られませんでした。



まず、モジュール性。



ボットのエンジン（「コア」）は、インスタントメッセンジャーと他のシステム（銀行のバックオフィスの特殊な部分であるペイメントカードシステム）の両方と直接通信しませんが、専用のモジュール（「コネクタ」）を介して通信します。 また、データサービスは分離されています。 したがって：

• インスタントメッセンジャーおよびその他のシステムへのコネクタのセット。
• コア（それより少し低い）;
• データサービス。
• 他のいくつかのサービス（例は、銀行による取引レートの最終確認の単純だが重要なサービスです）。

ところで、モジュールの相互作用もREST APIを使用しています。



メッセンジャーユーザーからメッセージが到着すると、対応するコネクタがカーネルに送信し、カーネルがそれを分析し、応答メッセージを生成します（これにはデータサービスと多くの場合他のサービスの両方が必要です）。 。 これにより、次のことが可能になりました。

• さまざまなメッセンジャーと連携するためのすべての仕様と設定をコネクタのレベルに引き上げます。 Viberは、Facebook Messengerとは異なり、キーボードのボタンのフォントと色を変更できますか？ コネクタ設定でブランドブックに従ってそれらを「色付け」してください。 Facebook Messengerにはカルーセルがありますか？ コネクタを構成して、ブランチの表示に応じて、これらのブランチがカルーセルで表されるようにします。 しかし、ボットカーネルはこれらの機能を「知る」必要はありません。
• 必要に応じて、ボットを他のメッセンジャーに配布するために、新しい（新しい）コネクタを開発し、他に何も触れずにプールに追加することによってのみ。
• -必要に応じて、コネクタおよび他のモジュールを異なるホストに配布します。

第二：「テキストコンテキストサブテキスト」の概念。



簡単に言えば、この概念の枠組み内で、ボットコアの応答は、ユーザーのメッセージのテキスト（半身的には、ユーザーが送信する位置情報、テキスト）だけでなく、コンテキスト（ユーザーがボットとの対話中の状態、「今」、ユーザーが今話していること））、さらに、サブテキストから（この特定のユーザーだけでなく、ダイアログの_history_、「以前の会話は何でしたか」）。



おそらく、そのような概念は、無限のメモリ（サブテキスト）を備えたMiles有限状態マシン（text-context-> new context-response）の観点から実装できると既に推測しているでしょう。 ただし、詳細に入らない場合は、例を使用して説明するのが最も簡単です。



ユーザーはボットに「注文」メッセージを送信します。 Text = "order"、しかしテキストを知るのに十分ではありません。 カーネルはデータサービスにアクセスし、このユーザーの現在のコンテキストを取得します。 （参照用-現在、200を少し超えるコンテキストがあり、プログラミングなしで構成できます）。



受信したコンテキストが「ユーザーが銀行の従業員にメッセージを送信する」場合、サブテキストは必要ありません。メッセージを銀行に送信し、すべてが送信されたことをユーザーに伝え、しばらくすると彼に連絡し、新しいコンテキスト「メインメニュー」に入ります。



結果のコンテキストが「メインメニュー」の場合、サブテキストも必要です。 つまり、カーネルはデータサービスからサブパスを受け取ります。サブテキストは、このユーザーの正式な（パスポートのような）姓、名、ミドルネーム、および電子メールアドレスのセットで構成されます。 そして今、ボットの答えはサブテキストに依存しています。 そのようなサブテキストが空でない場合（つまり、ユーザーが以前にボットに報告したことを意味します）、ボットはそれを使用する（または必要に応じて変更する）ことを提案し、注文します。 そのようなサブテキストが空の場合、注文するための条件としてのボットは、このデータを報告する必要性を与えます。 データが受信されると、必要なサブテキストが表示され、注文を行うことができます。 次のコンテキストは、「すべてのユーザーデータを受信しました。注文を続行します」です。 これらすべてにより、履歴が蓄積されていることは明らかです（これは、新しいコンテキストを取得するために使用されます）。



素晴らしいですが、NLPはどこにありますか？ 確かに、NLP（Natural Language Processing）は非常にファッショナブルな略語になりました。 しかし今のところ、ここHabrahabrでさえ、自然言語処理は神経言語プログラミングと混同されることがあります。 そして、NLP-「プログラミング」と同様に、NLP-ロシア語の処理は、期待どおりに機能しません。 さらに、もう1つ微妙な点があります-私たちの意見（および他の専門家の意見）では、ユーザーはボットと人としてコミュニケーションを取りたくありません。 彼はこれがプログラムであることを理解しており、ボタン、色、写真などのプログラムのようなUIを取得したいと考えています...



しかし、レモンがあれば、それからレモネードを作ることができます。 それが私たちの理由です：

-「純粋なチャット」ではなく「チーム」ボットを作成することが望ましい。

-NLPサービスをモジュール（上記のカーネルのサービス）として使用します。これは、コンテキストとサブテキストと共に、ユーザーが望むものをテキストで解析することを可能にします。 このモジュール（コンテキストによって異なります！）カーネルによって分析されるオブジェクトの配列を返します。 簡単な例は、コンテキストが「主要な交換パラメータを選択する段階で注文を配置する」場合、「500ドル」というテキストに対して、この特定のサービスは配列を生成します。

{    "deal_candidates":    [ { "direction": "buy", "amount":500, "ISOCode": "USD"}, { "direction": "sell", "amount":500, "ISOCode": "USD"} ] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてすでにこの配列にあるボットのコアは、「あなたが欲しいものを選択してください」と尋ねます。



私たちの経験の結果：

• 金融サービス向けの便利なトランザクションボットを行うことができ、実行する必要があります。
• 「これらのボット（および、それに応じてサービス）を使用すると、迅速、効率的、そして最も重要なこととして、スケーラブルで複製可能な実証済みのアプローチがあります。」

サイトがサイトだけでなくチャットボットにも選ばれた理由：

• メッセンジャーは非常に多くのユーザーによって使用されます。専用のモバイルアプリケーションを個別に検索してインストールする必要はなく、ボットを連絡先リストに追加して対話を開始するだけです。
• メッセンジャーでの操作-これは使い慣れたインターフェイスでの作業です-金融取引への便利なアクセスが実現している間、必要な機能を再学習したり検索したりする必要はありません。
• 銀行は、次のボットを開始することにより、新しい通信チャネルに対する顧客の関心の高まりを考慮しています。

VTB24は、将来的にすべての利用可能なメッセンジャーでチャットボットをリリースする予定です（ViberとVkontakteを追加し、WhatsApp APIが開くのを待ちます）。



また、すべての困難にもかかわらず、より便利なユーザーインタラクションのためにNLPトピックを掘り下げていきます。 チャットボットは銀行のウェブサイトの個人アカウントで既に機能しています。チャットボットを使用して、チャットボットからアドバイスや支援を受けられます。 このボットの作業とトレーニングの結果は、インスタントメッセンジャーのコンバージョンチャットボットに実装されます。



また、外国為替取引だけでなく、チャットボットが提供する金融サービスの範囲を拡大する予定です。



オフラインコースをオンラインで修正することは、人々にサービスを提供するための重要な新しいチャネルです。



これは真の革新的なサービスであり、銀行サービスのデジタル化におけるもう1つの小さなステップです。 この新しいサービスにより、現金通貨を「今ここで」交換することができます。 同時に、銀行はマスセグメントの消費者に近づいています。サービスを利用するためにVTB24の顧客である必要はありません。ロシアの銀行のカードがあれば十分です。



VTB24にとって、これは、さらなる技術開発のベクトルを決定するために、新しいテクノロジーを試してテストする絶好の機会でもあります。