Otkritie Mobile Bank：反対側からの開発

「まず、便利な登録メカニズムが発明され、次に-それを保護する手段」

iOSスマートフォン向けモバイルバンクの開発に関するケーススタディ











銀行3.0-銀行革命が本格化

銀行部門では、現在、ITは重要な構造変化を経験しています。 このプロセスはデジタル変換と呼ばれます。 ITが以前の遠いIT時代に形成されたビジネスプロセスを自動化するために使用され、それらの効率のパーセントを絞り込もうとするようになった場合、IT機能は今までなかった新しいビジネスモデルに取って代わります。 ここでは、モビリティが重要な役割を果たします。



「今日の銀行はあなたが行く場所ではなく、あなたがすることです」と、ベストセラーの銀行3.0の著者であるブレット・キングは書いています。 支店がクライアントに幸福をもたらす唯一のものであると信じている人は誰でも、今日の消費者のための戦いにすでに負けています。 わずか10年前、取引の50〜60％が銀行支店のレジで行われました。 現在、操作の95％はインターネット、携帯電話、ATM、コールセンターを介して行われています。 クライアントは年に1〜2回しか銀行支店に行きたくありませんが、通常は以前よりも頻繁に銀行とやり取りします。スマートフォンを使用して月に20〜30回、タブレットを使用して7〜10回。



モバイル銀行：原価センタではなく利益センタ

ロシアでは、毎月660万人がモバイルデバイスから少なくとも1回オンラインで支払いを行っています。 ただし、多くの銀行は、モバイルアプリケーションを、非常に高度な若い視聴者の嗜好を満足させるための不幸な必要性（および費用）と考えています。 すでにインターネット銀行があります-それを使用してください！ いいえ、彼らは確かにネイティブアプリケーションが必要です！ OK このアプローチにより、第一波モバイル銀行のほとんどが市場に投入されました。 予想通り、彼らは事業の成長に弾みをつけず、費用に陥りました。 そのため、顧客はモビリティに関して一定の疑念を抱いています。



しかし、銀行サービスの全体的な構造におけるモバイルチャネルの役割は劇的に変化しました。 補助モバイルバンキングが主なものになりつつあります（さまざまな推定によると、モバイルテクノロジーを使用するクライアントは、銀行に約5倍の収入をもたらします）。 さらに、銀行を選択する際、消費者はモバイルバンキングアプリケーションの品質を検討し始めました。



顧客のほぼ半数（48％）は、モバイルアプリケーションの品質が銀行の変更を決定する重要な要素であると考えています。





顧客が望んでいることを知っているとき

アプリケーションの理想的な顧客は、ビジネスにおけるITの重要性を理解している技術ベースの企業です。 銀行はこの価値を理解するだけでなく、特にITに基づいてビジネス全体を構築します。 銀行側のプロジェクトに参加しているワーキンググループ（IT、セキュリティ、マーケティング、顧客との連携など）は、技術やビジネス上の利点について説明する必要はありません。



（モバイルバンキングを含む顧客とのマルチチャネルインタラクションの開発に関する顧客に対する明確な戦略の欠如は、プロジェクトの重大なリスクと見なされるべきです。）



Otkrytieは、顧客にクールなサービス、明確なビジネスニーズを提供したい若いモビリティチームであり、Redmadrobotによって開発中に具体化されました。



Otkritieにとって、モバイルバンクは、iPhoneだけでなく、さまざまなプラットフォームやデバイスで利用可能な単一の統合サービスシステムの一部です。 スマートフォン向けのAndroidバージョン（今年のGoogle Playで登場予定）とタブレットバージョンでの作業はすでに進行中です。 銀行はすべてのインターフェイスを更新します。ATMと電子回線の再設計が開始され、支払い端末が近づいています。 モバイルアプリは、この更新コンセプトの一部です。

アプリケーションを開発する際、私たちは2つの重要なタスクに導かれました：銀行の個人顧客の基本的なニーズを満たし、金融機関自体のビジネスニーズを満たします（銀行サービスのシンプルさと利便性のアイデアを伝えることで、銀行商品を販売するための追加チャネルを獲得し、顧客の忠誠心を高めるため）。 私たちにとって、モバイルバンクはサービス販売のもう1つのチャネルです。

理想的には、すべてのお客様にモバイルアプリケーションがインストールされるように努めています。 結局のところ、現在のスマートフォン市場は、デバイスがもはや信じられないほど高価ではないレベルに達しました。 注意が必要な主な指標は、成功した登録の数です。 つまり、登録プロセスを非常に明確にして、誰も「登録方法」または「クリックして何をするのか」という質問がないようにすることが重要でした。

Alexey Kruglov、上級副社長、マーケティングおよびクライアントサービスディレクター、Otkritie Bank





設計と安全性が重要な利点です。

モバイルアプリケーションの開発者は、銀行商品の構成に一切影響を与えることはできません-一連のサービスは金融機関の専門家によって形成されます（さらに、これらのサービスはすべての銀行でほぼ同じです：口座情報、支払い、振替、明細書、通貨換算など）。 したがって、何をすべきかではなく、HOWに焦点を当てる価値があります。



UXとコードの品質はどうですか。 Discoveryプロジェクトでは、デザインはモバイル製品の競争上の優位性と見なされていました。 セキュリティに特に注意が払われました-仕事を妨げないという意味で。 はい、正確に。 一方で、セキュリティは非の打ちどころのないものである必要があります（システム全体を危険にさらすのに重要なインシデントが1つあれば十分であり、ここでは設計が役に立たないため、ユーザーはそれを拒否します）。一方で、製品とその機能を単純化することで完璧を達成すべきではありません。







優れた設計への道は、多くの反復を通してです。

すぐれた設計を採用して実行することはできません。 たとえビジネス要件、ブランドブックなど、すべてが原則として明確な場合でも、1つの画面に10のオプションがあります。卓越性への道の制限ではありません。 しかし、顧客が受け入れ、承認したオプションでさえも変更する必要がありました。



（プロジェクト管理でバージョン管理を確立することは非常に重要です。）



ブランドブック「Discoveries」は、iOSに少し適合させる必要がありました。Appleのガイドラインと伝統に従って、モバイルデバイスではインターフェイスがより明るくなっています。







ネイティブプロトタイプは、場合によっては贅沢品ではなく、必需品です

ほとんどの場合、インターフェースの設計と移行ロジックを評価するために、設計段階で簡単なHTMLプロトタイプサービスを使用できます。 ただし、この方法では、ダイナミクスを完全に評価し、将来のアプリケーションのインタラクティブ性を感じることはできません。 設計を重要な競争上の優位性にすることが決定された場合、そのようなニュアンスを無視することは不可能であったため、ネイティブプロトタイプを使用することを決定しました。つまり、UXテスト段階で製品を使用する完全な感覚を与えるために、実際のデータのみ、サーバー側なしで、ほぼ実際のアプリケーションを使用することを決定しました。



もちろん、より高価で複雑ですが、この場合、目的は手段を正当化しました。 そして、もちろん、このアプローチはどのプロジェクトでも正当化されません。







サイドでのユーザビリティテスト

使いやすさの場合、顧客と開発者がインターフェースの利便性と理解可能性についてコンセンサスを得られないリスクがあり、これが競合の基礎になります。 評価の主観性を完全に回避することはできません。また、良いインターフェースソリューションと見なされるものと悪いものについての各当事者の意見は、大きく異なる可能性があります。 そして最も重要なことは、ユーザーが自分自身のまったく異なる好みを持っていることが多いためです。







したがって、開発者は歓迎されるべきです。顧客がユーザビリティの専門家を見つけたら、この関係は破壊されるよりも強化されるでしょう。 このような「三角形」では、責任ゾーンをより合理的に分割できます。顧客がビジネス要件に対処し、開発者が設計を行い、ユーザビリティー担当者がフィードバックを行います。



Otkrytie Bankは、ユーザビリティテストパートナーとしてUsethicsを選択しました 。

テストシナリオは、製品の最初のバージョンの機能の約70％（登録、アプリケーションへの再入力、アカウント情報の表示、支払い履歴、サービスの支払い、支店およびATMの検索）を対象としました。 回答者は、iPhoneユーザーとインターネットバンキングの中から選ばれました。



設計者はテストプロセスを見て、ユーザーを心配していました。正しいボタンが見つかるかどうかはわかりませんか？ 時々それが見つからなかった場合、インターフェースは修正され、再度テストされました。







テスト結果によると、アプリケーションの使用による主観的な満足度は92.8％であり、一般に、回答者の98％がOtkritieモバイルバンクに対して肯定的な評価をしました。



しかし、幸福感に陥るべきではありません。実際の作業では、モデルデータでユーザビリティがテストされ、すべてのタイプのユーザーが対象となるわけではないため、修正が必要なインターフェイスの問題が特定されます。



アプリケーションには「カスタマイズ」が必要

「Pay」アクションを、スマートフォンを含むスライダーのようなスライダーにするというアイデアは、プロジェクトのすべての参加者を本当に気に入りました。 さらに、Appleのガイドラインと完全に一致しており、不満を言うことはありません。







ただし、このバージョンのApp Storeは「アプリケーションにはカスタマイズがありません」という言葉でまとめられています。システムコンポーネントを目的に使用することはできません。 つまり、アプリケーションはオリジナルで、システム画面とは異なるはずです。 悲しいかな、私は支払いのためにスライダーから離れなければなりませんでした。



均一性と標準化-常に良いとは限らない

同様の機能が同様の画面を持つように、インターフェースの均一性に努めることが慣習です。 ただし、このルールが機能しない場合があります。



アプリケーションに入るには、ユーザーはアクセスコードを入力する必要があります。 しかし、最初にこのコードを作成する必要がありますか？ 開発者にとって、これらの画面を同一のデザインで作成することは論理的に思えました。 もちろん、画面上の碑文は異なっていました-「コードを入力してください」と「コードを作成してください」。 ユーザビリティテストの過程で、ユーザーが混乱しており、システムがコードを作成するように求めたときにシステムが何を望んでいるのかを理解していないことが判明しました。 したがって、これらの画面を視覚的に明確に区別できるようにし、同時にテキストによる説明を追加することにしました。







（ユーザーの注意力に頼らないでください。混乱する可能性があるものは混乱します。ほぼマーフィーの新しい法律です。）



アプリケーションのコピーライティング：「ファイルを保存しない：はい/いいえ？」

ファイル保存ダイアログに関するこの古いジョークは、依然として関連しています。 多くの場合、ユーザーは、アプリケーションの機能の名前、質問の言葉遣い、プロンプト、その他のテキストメッセージに戸惑いますが、デザイナー自身はすべてが明確であると考えています。



「アクセスコードを作成する」という簡潔なコメントのユーザーは、単に気付かなかった。 したがって、外観を変更することに加えて、この画面でユーザーに要求されるかなり詳細な説明テキストを提供する必要がありました。







冗長性と冗長性を持たせたほうがよいでしょう。多くの場合、マイナスよりもプラスとして機能します。 ユーザーは最後の手段としてのみ指示を読むため、何も起こらなかったため、慣れ親しんだときに余分なテキストに注意を払わないことに慣れます。



安全性は-目に見えないものでなければなりません

銀行のモバイルアプリケーションが安全であるべきだということは、誰にとってもほとんどニュースではありません。 すべての開発者はこれを認識していますが、脆弱性は決して隔離されていません。







銀行は、リスクを最小限に抑えるためにモバイルアプリケーションを介してトランザクションのサイズを制限することが多く、それによってアプリケーションの範囲と収入の可能性を制限しています。



本当に安全なモバイルバンクを作成することは可能ですか？ あらゆる攻撃ベクトルに対して絶対に無敵です-絶対に不可能です。 保護方法は、原則として、発生して発見されたインシデントに応じて表示されるためです。 さらに、現在知られているほとんどの脅威に対する保護機能を備えた信頼性の高いアプリケーションを作成できます。 正しいコードと銀行の内部システムとの適切な相互作用による高度なセキュリティ。

銀行と協力して（Otkrytieは最初の銀行プロジェクトではありません）、安全なアプリケーションを作成するためのアプローチを再検討する必要がありました。 これは、作業の実践と実際にはコードの作成にあまり関係していませんでした-これで、以前はすべてうまくいきましたが、アーキテクチャの文書化と予備的な研究でした。 銀行のセキュリティサービスは脅威モデルに基づいて運営されており、特定の脅威にどのように対抗するかについて、合理的かつ明確な回答が必要です。 たとえば、中間者攻撃の際にIDスプーフィングの脅威をどうしますか？ 「このために、私たちはそのようなものを提供しました」と言います。 結果は2つのドキュメントです。

1）アプリケーションセキュリティの正式な要件-コード、アーキテクチャ、データストレージの要件

2）サーバー相互作用の要件

実際、プロジェクトで行われたすべての決定は、セキュリティ要件と一致していました。 プロジェクトの開始時に、セキュリティ作業が時間の25％を占めました。 その後、アーキテクチャの決定が下されたとき、情報セキュリティの問題にほとんど時間を費やしませんでした。

アーサー・サハロフ、 mc_murphy 、 Redmadrobotの CTO





品質保証-プロジェクトの最初の段階から

Redmadrobot QAチームは、分析段階でプロジェクトに参加しました。 これにより、開発およびテスト段階での大規模な変更を回避できました。 テストケースとテスト計画には、機能テストとUI \ UXテストだけでなく、セキュリティテストも含まれています。



顧客側のアプリケーションでは、個人アカウントと同じサーバー部分が使用され、モバイルバンクのテスト中に欠陥が検出され、その修正によりすべてのOtkrytie金融サービスの作業が改善されました。



HP Fortify-一流のセキュリティチェック

Hewlett-Packard Fortify Static Code Analyzerは、世界市場で利用可能な最も深刻なソフトウェアセキュリティアシュアランス（SSA）検証ツールの1つです。 HP Fortifyの独立した専門家は、Otkritieモバイルバンクの37,225行のソースコードをチェックしました-アナライザーは重大なセキュリティ脆弱性を特定しませんでした。



アナライザーは、アプリケーションとサーバーのソースコードをスキャンし、それらから可能な攻撃ベクトルと保護シナリオを決定します。その後、結果に優先順位を付け、詳細なレポートを提供します（コードの個々の行のレベルまで）。 データの操作には最大の注意が払われます-データがディスクに保存されるか、保護されていない形式で転送されるか、スクリーンショットがiOSでマスクされるかどうか。



一意：クレジットカードによるアプリケーションへの登録

多くの場合、モバイルバンクの使用を開始するのはそれほど簡単ではありません。部門内でユーザー名とパスワードを取得するか、別の方法でアプリケーションの登録などを待つ必要があります。 「発見」プロジェクトには、すべての遅延を取り除き、クライアントにモバイルバンクのユーザーになるべく簡単な機会を与えるという課題がありました。



元のソリューションを見つけることができました。クライアントは自分の銀行カード番号で登録するため、ログインとパスワードはもう必要ありません。 セキュリティ上の理由からカード番号自体をデバイスに保存できないため、登録に使用される識別子の独自のメカニズムを考案する必要がありました。 アプリケーションは新しい識別子を生成し、サーバーに送信します。 サーバーは確認コードを含むSMSを送信します-それだけです。モバイルバンクを使用できます。 当然、サーバーとのやり取りは、標準のiOSライブラリとHTTPSプロトコルを使用して、暗号化された形式で行われます。



ユーザーの生活を楽にするために、認識機能がアプリケーションに組み込まれました。銀行カードにiPhoneカメラを向けるだけで、登録が自動的に行われます（カードがエンボスされている場合）。 次に、PINコードを作成し、それを使用してアプリケーションを入力する必要があります。 電話が紛失した場合にアプリケーションをブロックできるため、十分に安全です。 識別子は侵害されたものとしてマークされ、その下にあるシステムに入ることはできません。再登録する必要があります。



そして、はい-iOS 8のTouch IDログインもサポートされています。 ちなみに、Otkritieモバイルバンクは、指紋認証を備えたロシア市場で最初の銀行です。



サーバーと通信する：将来の基盤となるAPI

サーバー側には、モバイルクライアント用の単一のエントリポイントがあります。これは、銀行が開発したミドルウェアであり、CRM、支払い、プラスチックカードなど、すべての内部システムとさらに統合されています。

アプリケーションは、RESTful APIに基づいてサーバーと対話します。RESTfulAPIは、銀行の他のサービスやWebアプリケーションが使用できるように汎用化されています。 データモデルから始めて、いくつかの反復で作成されました。 そして、すぐに再利用と拡張の機会が見えました。 その結果、非常にシンプルで非常に便利でスケーラブルなインターフェイスが実現します。

これで、APIが1.5回から2回で、アプリケーションの最初のバージョンの機能とオーバーラップします。 一般に、アプリケーションの開発中に基本的なことを変更する必要がないように、アーキテクチャは将来の基盤を使用して作成する必要があります。

アーサー・サハロフ、 mc_murphy 、 Redmadrobotの CTO





何が行われ、次は何ですか

モバイルバンクの最初のバージョンは、標準の機能セットをサポートしています。

-再認証を簡単にするための個別のアクセスコードの作成。

-カード、ローン、預金に関する詳細情報。

-ステートメントを表示します。

-カードを迅速に補充する機能。

-モバイルバンキングとオンラインバンキングを通じて行われた支払いの一般的な履歴と、操作を繰り返す可能性。

-モバイル通信、有料テレビ、公共料金などの支払い。

-Otkritie銀行内での送金。

-お金の変換;

-最寄りのATMやオフィスのクイック検索。

-ホットラインまたはメールによる銀行サポートサービスへの迅速な連絡。

年末までに、申請書には他の銀行への送金、オンライン相談、抽出物の最終決定（フィルター、業務カテゴリー）などが含まれます。 リリースポリシーは、アプリケーションの安定性の向上と新しい機能の追加、顧客企業のビジネスニーズの満足度の追跡、および製品開発計画の更新を目的とした毎月の更新を意味します。

スマートフォン用のiOSバージョンに続いて、Androidおよびタブレットバージョン用のモバイルバンクが表示されます。