كل وسيط يطلب في النهاية تطبيقه الجوال الخاص. والمنطق سليم: العملاء يعيشون على هواتفهم، وتطبيق مزود المنصة يحمل شعار شخص آخر، وأيقونة بعلامتك التجارية على الشاشة الرئيسية للمتداول تستحق شيئًا. ثم يواجه المشروع فريق المراجعة في Apple ويتضاعف الجدول الزمني.
إليك ما هي الخيارات فعليًا، وما الذي يجب أن يفعله التطبيق، وأين يتم رفض الطلبات.
ثلاث طرق لوضع تطبيق تداول باسمك
الخيار الأول هو ألا يكون لديك واحد. يقوم عملاؤك بتنزيل تطبيق مزود المنصة واختيار خادمك. هذا لا يكلف شيئًا، ولا يحمل أي مخاطر على المتجر، ولا يمنحك أي علامة تجارية على الإطلاق. بالنسبة لشركة وساطة جديدة بكتاب أعمال صغير، يكون هذا غالبًا الخيار الصحيح للسنة الأولى.
الخيار الثاني هو تطبيق جوال White Label من مزود المنصة لديك، ويُنشر تحت شركتك. تقدم عدة جهات مزودة للمنصة هذا الخيار. تحصل على اسمك وألوانك على طرف تداول مُجرَّب، وتتحمل أنت الإدراج، وعملية المراجعة، ودورة التحديث. تكلفة التطوير منخفضة، لكن الالتزامات المستمرة حقيقية.
الخيار الثالث هو تطبيق مخصص مبني على CRM وواجهات برمجة تطبيقات التداول لديك. هذا هو المسار الوحيد الذي يمكن للتطبيق فيه أن يفعل كل ما يحتاجه العميل في مكان واحد: التسجيل، رفع المستندات، تمويل الحساب، فتح حساب تداول جديد، ورؤية الأرصدة إلى جانب الرسم البياني. وهو أيضًا الأغلى في التطوير، والوحيد الذي تتحمل فيه أنت كل عملية رفض.
ومن الجدير أن نكون صريحين بشأن الخيار الثالث: بالنسبة لمعظم الوسطاء، لا يكون طرف التداول هو عامل التمييز. المتداولون الذين يهتمون بالتحليل البياني لديهم بالفعل MetaTrader أو cTrader مثبتًا، ولن ينتقلوا إلى نسختك من شمعة بيانية. الجزء من التجربة الذي يخصك فعلًا هو منطقة الحساب، ولهذا السبب تتولى كثير من التطبيقات المخصصة إجراءات الانضمام والتمويل وإدارة الحساب، وتسلّم شاشة التداول الفعلية إلى تطبيق المنصة.
ما الذي يجب أن يفعله التطبيق إلى جانب عرض الرسوم البيانية
توسع النطاق يقتل هذه المشاريع، لذا حدد مبكرًا أيًّا من هذه ستكون في الإصدار الأول:
- التسجيل وتسجيل الدخول، ويفضل أن يكونا مشتركين مع منطقة العميل على الويب حتى لا يضطر العميل إلى إدارة هويتين.
- رفع المستندات باستخدام كاميرا الهاتف، وهو أكبر سبب يجعل الانضمام عبر الهاتف يتفوق على الانضمام عبر سطح المكتب في معدل الإكمال.
- الإيداعات والسحوبات، بما في ذلك أي طرق محلية تستخدمها مناطقك فعليًا.
- قائمة الحسابات، والأرصدة، والرافعة المالية، وبيانات اعتماد المنصة.
- إشعارات الدفع للهوامش، والموافقات على المستندات، وحالة الدفع.
تصف هذه القائمة عبارة عن غرفة المتداول داخل غلاف تطبيق، وهذا بالضبط ما ينبغي أن تكون عليه. إذا كانت البيانات نفسها تشغّل بالفعل بوابة الويب لديك، فإن تطوير الجوال يكون مشروع واجهة لا مشروع منصة. إن CRM API هو ما يطوّر عليه مطور الجوال، ومن المفيد التحقق من أنه يوفّر كل ما في القائمة قبل أن يكتب أي شخص سطرًا واحدًا من Swift. لدى Prop firms قائمة مشابهة بمحتويات مختلفة، لأن الشاشة المكافئة هنا هي لوحة التحدي مع تقدّم القواعد، والتراجع، وحالة الدفعات.
ويستحق Push ملاحظة خاصة. فهو في كثير من الحالات السبب في بناء تطبيق أصلًا، لأنه القناة الوحيدة التي تصل إلى المتداول دون منافسة البريد الوارد. نداءات الهامش، وموافقات التحقق، والإيداعات الفاشلة هي الإشعارات التي يريدها العملاء فعلًا، ويجب أن تنطلق من نظام الإشعارات الذي يستخدمه CRM لديك بالفعل، لا من أداة منفصلة لا يديرها أحد.
المرور عبر مراجعة Apple
أربع إرشادات تفسر معظم حالات الرفض في هذه الفئة.
- الإرشاد 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.” عمليًا، هذا يعني أن حساب المطور يعود إلى الكيان المرخّص لديك، وأن الاسم على الحساب يطابق الاسم في الترخيص، وأن توافر التطبيق حسب البلد يطابق الأماكن التي لديك فيها إذن فعليًا. التطبيق الذي يقدّمه وكيل تطوير نيابةً عنك يطلب رفضًا على الأرجح.
- الإرشاد 4.3(b) يغطي التطبيقات التي هي “indistinguishable from what’s already widely available.” النسخ ذات العلامة التجارية من نفس طرف التداول تقترب بشكل مزعج من هذا الخط، ولهذا كانت نسخ كل وسيط على حدة من منصة معروفة مسارًا صعبًا لسنوات. الدفاع هنا هو أن تطبيقك يفعل ما لا يفعله التطبيق العام، وهذا سبب آخر لبناء منطقة الحساب بدلًا من شاشة رسوم بيانية أخرى.
- الإرشاد 4.2 يلتقط التطبيقات الضعيفة. إذا كان ما ترسله مجرد غلاف web view لبوابة العملاء لديك من دون أي عناصر أصلية فيه، فتوقّع أن يُسأل ما الذي يضيفه التطبيق مقارنةً بالموقع المحمول. التقاط المستندات بالكاميرا، وتسجيل الدخول البيومتري، وإشعارات Push هي الإجابات المعتادة، ويجب أن تكون موجودة قبل الإرسال لا أن تكون مجرد وعد في ملاحظات المراجعة.
- الإرشاد 5.1.1 يتطلب سياسة خصوصية توضح ما الذي تجمعه، وكيف تستخدمه، ومع من تشاركه، وكيف يحذف المستخدم بياناته. وتتوقع Apple أيضًا إتاحة حذف الحساب داخل التطبيق. بالنسبة لوسيط خاضع للتنظيم وله التزامات حفظ السجلات، يجب أن تكون هناك إجابة حقيقية هنا، وعادةً تكون حذف حساب التطبيق مع بيان واضح لما يجب الاحتفاظ به قانونًا ومدة الاحتفاظ.
هناك أمران عمليان يختصران المراجعة: امنح المراجع بيانات دخول تجريبية تعمل على حساب يحتوي على أموال ومراكز مفتوحة، وأرفق تسجيلًا قصيرًا للشاشة يوضح التدفق. المراجعون الذين لا يستطيعون تجاوز بوابة KYC الخاصة بك سيرفضون بدلًا من التحقيق.
سؤال الشراء داخل التطبيق بالنسبة إلى Prop firms
تواجه Prop firms مشكلة إضافية. الإرشاد 3.1.1 يتطلب الشراء داخل التطبيق لفتح الميزات أو المحتوى، ويحظر صراحةً استخدام آليتك الخاصة لذلك. وما إذا كانت رسوم التحدي تُعد محتوى رقميًا هو سؤال تريد الإجابة عنه قبل بناء التدفق، لا بعده، لأن فرق العمولة كبير بما يكفي لتغيير اقتصاديات الوحدة لديك.
النمط الآمن الذي يستخدمه معظم المشغلين هو إبقاء مشتريات التحدي على الويب، والسماح للتطبيق بعرض وإدارة الحسابات التي يمتلكها المتداول بالفعل. قواعد Apple بشأن الربط إلى المشتريات الخارجية تغيّرت عدة مرات في السنوات الأخيرة وتختلف حسب المنطقة، لذا اقرأ النص الحالي للإرشاد بدلًا من منشور مدونة يعود لعامين، بما في ذلك هذا النص.
Google Play
Play عادةً أسرع، لكنه يتطلب أوراقًا خاصة به. أي تطبيق يتضمن ميزات مالية يجب أن يُكمل إفصاح Financial features في Play Console، كما أن سياسة Financial Services تفرض متطلبات إضافية تختلف حسب البلد، بما في ذلك وثائق الترخيص في بعض الأسواق. املأ الإفصاح بصدق من المرة الأولى، لأن التصحيحات بعد الرفض أبطأ من المراجعة الأصلية.
ستحتاج أيضًا إلى قسم «أمان البيانات» مكتملًا يتوافق مع سياسة الخصوصية الخاصة بك، ويجب أن تخطط لمتطلبات مستوى واجهة برمجة التطبيقات المستهدف من Google، والتي تفرض تحديثًا تقنيًا كل عام سواء تغير منتجك أم لا.
هناك أمر آخر يستحق التحقق منه قبل أن تكتب نص المتجر: قواعد الإعلانات الخاصة بالمنتجات المالية المضاربية المعقدة تقيد كيفية وصفك للتداول في كلا المتجرين وفي الإعلانات. لقطات الشاشة التي توحي بالربح طريقة موثوقة للتعرض للإزالة.
خصص ميزانية للسنة الثانية، لا للإطلاق
عرض تكلفة التطوير هو الرقم الصغير. فكل عام يجلب إصدارات جديدة لأنظمة التشغيل، ورفعًا إلزاميًا لمستوى API على Android، وتحديثات SDK من مزود المنصة لديك، ودورة مراجعة لكل منها. التطبيق الذي لا يحصل على ميزانية صيانة يتوقف عن العمل خلال نحو ثمانية عشر شهرًا ويلحق بالعلامة التجارية ضررًا أكبر مما لو لم يكن موجودًا أصلًا.
إذا لم يكن بند الصيانة ممولًا، فالإجابة الصادقة هي منطقة عميل متجاوبة بدلًا من تطبيق. إنبوابة ويب للهواتفمُصممة جيدًا تتولى عمليات التسجيل، وتمويل الحساب، وإدارة الحساب على الهاتف، وتدعم إشعارات الويب الفورية على معظم الأجهزة، ولا تحتاج إلى موافقة المتجر، ويمكنها إطلاق تحديث في اليوم الذي تقرر فيه ذلك.
كيفية اتخاذ القرار
انظر إلى حصة حركة المرور في منطقة العميل لديك التي تأتي أصلًا من الأجهزة المحمولة وإلى ما تفعله تلك الجلسات. إذا كان معظمها يتعلق بالتحقق من الأرصدة ومتابعة الإيداعات، فسيكون التطبيق مفيدًا وسيكون النطاق واضحًا. وإذا كان الطلب يأتي من فريق مبيعات يريد شيئًا يعرضه على العملاء المحتملين، فإن بوابة ويب تحمل العلامة التجارية ستؤدي الغرض نفسه بجزء بسيط من التكلفة.
وعندما تبني، أطلق منطقة الحساب أولًا وأضف شاشة التداول لاحقًا إذا كانت الأرقام تبرر ذلك. نادرًا ما يطلب العملاء تطبيقًا لأنهم يريدون مخططات أفضل. إنهم يطلبونه لأنهم يريدون أموالهم ووثائقهم على بُعد نقرة واحدة، وهو ما يتماشى مع النمط الذي رأيناه عند مراجعةما يريده المتداولون فعلًا من وسيط.
اطلب استشارة بشأن تجربة العميل عبر الهاتف المحمول
احصل على إرشاد متخصص لاختيار استراتيجية الهاتف المحمول المناسبة لوسيطك أو لشركة Prop Firm الخاصة بك. سنساعدك على تقييم ما إذا كان التطبيق الأصلي، أو Traders Room تحمل العلامة التجارية، أو بوابة ويب متجاوبة هو الأنسب لعملك، وتوقعات العملاء، والمتطلبات التشغيلية.
معًا، سنراجع رحلة العميل الحالية لديك ونضع استراتيجية للهاتف المحمول مصممة للتوسع والاستدامة على المدى الطويل.
