すべてのブローカーは、やがて自社のモバイルアプリを求めます。その理由はもっともです。顧客はスマートフォンで生活しており、プラットフォームベンダーのアプリには他社のロゴが入っていて、トレーダーのホーム画面にブランドアイコンがあることには価値があるからです。しかし、そのプロジェクトがAppleの審査チームに回されると、納期は2倍になります。
ここでは、実際にどのような選択肢があるのか、アプリに何が求められるのか、そしてどこで審査が却下されるのかを説明します。
取引アプリを自社名で持つ3つの方法
1つ目は、そもそも持たないことです。顧客にはプラットフォームベンダーのアプリをダウンロードして、自社のサーバーを選んでもらいます。これは費用がかからず、ストア上のリスクもなく、ブランディングは一切ありません。小規模な口座数の新しいブローカーにとっては、最初の1年はこれが最適な判断であることが多いです。
2つ目は、プラットフォームベンダーが提供するホワイトラベルのモバイルアプリを自社名義で公開する方法です。複数のプラットフォーム提供元がこれを用意しています。実績のある取引端末に自社名とカラーを載せられ、掲載、審査プロセス、更新サイクルは引き継ぐことになります。開発費は低いですが、継続的な義務は現実に存在します。
3つ目は、CRMと取引APIの上に構築するカスタムアプリです。これこそ、顧客が必要とするすべてを1か所で完結できる唯一の手段です。登録、書類アップロード、入金、新規取引口座の開設、そしてチャートと並んで残高の確認ができます。費用は最も高く、却下の責任をすべて負うのもこの方法だけです。
3つ目の選択肢について率直に言うと、多くのブローカーにとって取引端末は差別化要因ではありません。チャート機能にこだわるトレーダーはすでにMetaTraderやcTraderを入れており、ろうそく足の見た目が少し違う程度で乗り換えることはありません。本当に自社の体験と言えるのはアカウント領域です。そのため、多くのカスタムアプリはオンボーディング、入金、口座管理を担い、実際の取引画面はプラットフォームアプリに任せます。
チャート表示以外にアプリがやるべきこと
機能が膨らみすぎるとこの手のプロジェクトは失敗します。ですので、次のうちどれをバージョン1に入れるかを早めに決めてください。
- 登録とログイン。理想的にはWebのクライアントエリアと共有し、顧客が2つのIDを管理しなくて済むようにします。
- スマートフォンのカメラを使った書類アップロード。モバイルでのオンボーディングがデスクトップより完了率で優れている最大の理由です。
- 入出金。対象地域で実際に使われているローカル決済手段を含みます。
- 口座一覧、残高、レバレッジ、プラットフォーム認証情報。
- 証拠金水準、書類承認、支払い状況に関するプッシュ通知。
この一覧はアプリ内の Traders Room を指しますが、それこそがあるべき姿です。同じデータがすでにWebポータルを支えているなら、モバイル開発はプラットフォーム開発ではなくインターフェース開発です。 CRM API はモバイル開発者が接続先にするものであり、誰かがSwiftで1行書く前に、この一覧のすべてを公開しているか確認する価値があります。Prop Firmでも内容は異なりますが、同様の一覧があります。該当する画面は challenge dashboard で、ルール進捗、ドローダウン、出金状況を表示します。
プッシュ通知は個別に触れる価値があります。多くの場合、アプリを作る理由そのものだからです。受信箱と競合せずにトレーダーへ届く唯一のチャネルだからです。証拠金不足アラート、認証承認、入金失敗は、顧客が実際に受け取りたい通知であり、別ツールではなく、CRMがすでに使っている同じ notification system から発火させる必要があります。誰も保守していない別システムからでは意味がありません。
Apple審査を通過するには
このカテゴリの却下理由の大半は、4つのガイドラインに集約されます。
- Guideline 3.2.1(viii)が最初に読むべき項目です。Appleの文言はこうです。”Apps used for financial trading, investing, or money management should be submitted by the financial institution performing such services and must have necessary licensing and permissions in the locations where you make them available.” 実務上は、開発者アカウントがライセンス保有主体のものであり、アカウント名がライセンス上の名称と一致し、配信地域が実際に認可を受けている場所と一致している必要があります。開発会社があなたの代理で提出する形は、却下を招く可能性が高いです。
- Guideline 4.3(b)は、”広く既に利用可能なものと見分けがつかない”アプリを対象にしています。同じ取引端末のブランド違いはこの境界線にかなり近く、よく知られたプラットフォームのブローカーごとのクローンは長年難しい手法でした。防御策は、一般的なアプリにはないことを自社アプリが行うと示すことです。これも、別のチャート画面ではなくアカウント領域を作るべき理由の一つです。
- Guideline 4.2は、内容の薄いアプリを取り締まります。提出物が、クライアントポータルをそのままWebビューで包んだだけでネイティブ要素が何もないなら、そのアプリがモバイルサイトに対して何を追加しているのかを問われるでしょう。カメラによる書類撮影、生体認証ログイン、プッシュ通知が通常の答えですが、審査コメントで約束するのではなく、提出前に実装しておく必要があります。
- Guideline 5.1.1は、何を収集し、どう使い、誰と共有し、ユーザーがどのようにデータを削除できるかを明記したプライバシーポリシーを求めます。Appleはアプリ内でアカウント削除を可能にすることも期待しています。記録保持義務のある規制対象ブローカーでは、これに対する現実的な対応が必要で、通常はアプリ口座の削除に加え、法令上保持しなければならない情報とその保持期間を明確に示します。
審査を短縮する実務的な工夫が2つあります。1つは、残高と建玉のあるアカウントのデモ用認証情報を審査担当者に渡すこと。もう1つは、操作フローの短い画面録画を添付することです。KYCの壁を越えられない審査担当者は、調査するより却下を選びます。
Prop Firmにおけるアプリ内課金の問題
Prop Firmには追加の問題があります。Guideline 3.1.1は、機能やコンテンツの解除にアプリ内課金を求めており、そのために自社の仕組みを使うことを明確に禁じています。チャレンジ費用がデジタルコンテンツに当たるかどうかは、実装後ではなく実装前に確認すべき論点です。なぜなら、手数料の違いがユニットエコノミクスを変えるほど大きいからです。
多くの運営者が採る安全な形は、チャレンジ購入はWebに残し、アプリではトレーダーがすでに保有している口座の表示と管理を行うことです。外部購入へのリンクに関するAppleのルールは近年何度も変わっており、地域によっても異なるため、2年前のブログ記事ではなく、最新のガイドライン本文を確認してください。もちろん、この記事も含めてです。
Google Play
Playは一般に審査が速いですが、必要書類はあります。金融機能を持つアプリは、Play ConsoleでFinancial features declarationを完了しなければならず、Financial Services policyでは国ごとに異なる追加要件が定められています。市場によってはライセンス文書も必要です。最初に正直に申告してください。却下後の修正は、最初の審査より時間がかかります。
また、プライバシーポリシーに一致する完成済みの Data safety セクションも必要になります。さらに、Google の target API level 要件にも備えておく必要があり、これは製品に変更があろうとなかろうと毎年の技術更新を強制します。
ストア掲載文を書く前に確認しておくべき、もう一つの重要な点があります。複雑な投機性金融商品の広告規制により、両方のストアや広告で取引をどう説明できるかが制限されます。利益を示唆するスクリーンショットは、確実に削除対象になる方法です。
ローンチではなく、2年目の予算を見込んでください
開発見積もりは小さな数字にすぎません。毎年、新しい OS リリース、Android の必須 API level 引き上げ、プラットフォームベンダーからの SDK 更新、そしてそれぞれに対するレビューサイクルが発生します。保守予算のないアプリは 18 か月ほどで動かなくなり、持たないよりもブランドへの悪影響が大きくなります。
保守費用が確保されないなら、正直な答えはアプリではなくレスポンシブなクライアントエリアです。適切に作られた mobile web portal なら、スマホ上でオンボーディング、入金、口座管理を扱え、多くの端末で web push をサポートし、ストア審査も不要で、あなたが更新したいと思ったその日にアップデートを配信できます。
判断のしかた
クライアントエリアへのトラフィックのうち、どれだけがすでにモバイルか、そしてそのセッションで何をしているかを見てください。ほとんどが残高確認や入金の追跡なら、アプリは役に立ち、範囲も明確です。もし需要が、見込み客に見せるものが欲しい営業チームから来ているなら、ブランド付きの web portal で同じことを、はるかに低いコストで実現できます。
実際に作るなら、まず口座エリアを先に出し、数値が妥当なら後から取引画面を追加してください。クライアントがアプリを求める理由は、より良いチャートが欲しいからとは限りません。多くは、資金と書類にワンタップでアクセスしたいからです。これは、私たちが ブローカーに対してトレーダーが実際に何を求めているか.
モバイルのクライアント体験に関するご相談を申し込む
ブローカーやProp Firmに最適なモバイル戦略の選定について、専門的なガイダンスをご提供します。ネイティブアプリ、ブランド化されたTrader Room、レスポンシブなWebポータルのいずれが、貴社のビジネス、顧客の期待、運用要件に最も適しているかを評価するお手伝いをします。
現在のクライアント導線を一緒に確認し、長期的な拡張性と保守性を見据えたモバイル戦略を策定します。
