Applications de trading mobile pour les brokers et les Prop Firms : White Label, développement sur mesure et validation sur l’App Store

Chaque broker finit par demander sa propre application mobile. La logique est solide : les clients vivent sur leur téléphone, l’application du fournisseur de la plateforme affiche le logo de quelqu’un d’autre, et une icône à votre marque sur l’écran d’accueil d’un trader a de la valeur. Puis le projet arrive devant l’équipe de validation d’Apple et le calendrier double.

Voici quelles sont réellement les options, ce que l’application doit faire, et où les soumissions sont rejetées.

Trois façons de mettre une application de trading à votre nom

La première option est de ne pas en avoir. Vos clients téléchargent l’application du fournisseur de la plateforme et sélectionnent votre serveur. Cela ne coûte rien, ne comporte aucun risque de rejet sur les stores et ne vous offre aucune image de marque. Pour un nouveau broker avec un petit portefeuille, c’est souvent la bonne décision pour la première année.

La deuxième est une application mobile White Label de votre fournisseur de plateforme, publiée au nom de votre société. Plusieurs éditeurs de plateforme proposent cela. Vous obtenez votre nom et vos couleurs sur un terminal de trading éprouvé, et vous héritez de la fiche, du processus de validation et du cycle de mise à jour. Le coût de développement est faible, mais les obligations récurrentes sont bien réelles.

La troisième est une application sur mesure construite à partir de votre CRM et de vos APIs de trading. C’est la seule solution où l’application peut tout faire en un seul endroit pour un client : s’inscrire, téléverser des documents, approvisionner le compte, ouvrir un nouveau compte de trading et consulter les soldes à côté du graphique. C’est aussi la plus coûteuse à développer et la seule où vous portez chaque refus.

Il faut être franc au sujet de la troisième option : pour la plupart des brokers, le terminal de trading n’est pas le facteur différenciant. Les traders qui se soucient des graphiques ont déjà MetaTrader ou cTrader installé et ne vont pas changer pour votre version d’une bougie japonaise. La véritable partie de l’expérience qui vous appartient, c’est l’espace client ; c’est pourquoi de nombreuses applications sur mesure gèrent l’intégration, le financement et la gestion du compte, puis confient l’écran de trading lui-même à l’application de la plateforme.

Ce que l’application doit faire en plus d’afficher des graphiques

L’accumulation de fonctionnalités tue ces projets, donc décidez tôt lesquelles figurent dans la version un :

• Inscription et connexion, idéalement partagées avec votre espace client web afin qu’un client n’ait pas à gérer deux identités.
• Téléversement de documents via la caméra du téléphone, qui est la principale raison pour laquelle l’intégration mobile dépasse l’intégration desktop en taux de complétion.
• Dépôts et retraits, y compris les méthodes locales réellement utilisées dans vos régions.
• Liste des comptes, soldes, effet de levier et identifiants de la plateforme.
• Notifications push pour les niveaux de marge, les approbations de documents et le statut des paiements.

Cette liste décrit un Traders Room dans un habillage d’application, ce qui est exactement ce qu’il doit être. Si les mêmes données alimentent déjà votre portail web, le développement mobile relève d’un projet d’interface plutôt que d’un projet de plateforme. L’API CRM est ce sur quoi un développeur mobile construit, et il vaut la peine de vérifier qu’il expose tout ce qui figure sur la liste avant que quiconque n’écrive une ligne de Swift. Les Prop Firm ont une liste similaire avec un contenu différent, puisque l’écran équivalent est le tableau de bord des challenges avec l’avancement des règles, le drawdown et le statut des paiements.

Les notifications push méritent une note à part. Elles sont, dans de nombreux cas, la raison même de créer une application, car c’est le seul canal qui atteint un trader sans entrer en concurrence avec une boîte de réception. Les appels de marge, les approbations de vérification et les dépôts échoués sont les notifications que les clients veulent réellement, et elles doivent provenir du même système de notification que votre CRM utilise déjà, plutôt que d’un outil séparé que personne ne maintient.

Passer l’examen d’Apple

Quatre directives expliquent la plupart des refus dans cette catégorie.

• Directive 3.2.1(viii) est celle à lire en premier. Le texte d’Apple : « Les applications utilisées pour le trading financier, l’investissement ou la gestion de fonds doivent être soumises par l’institution financière qui fournit ces services et doivent disposer des licences et autorisations nécessaires dans les lieux où vous les mettez à disposition. » En pratique, cela signifie que le compte développeur appartient à votre entité agréée, que le nom du compte correspond au nom figurant sur la licence, et que la disponibilité par pays correspond aux zones où vous êtes réellement autorisé. Une application soumise par une agence de développement en votre nom s’expose à un refus.
• Directive 4.3(b) concerne les applications « indiscernables de ce qui est déjà largement disponible ». Les variantes brandées d’un même terminal de trading se situent dangereusement près de cette limite, c’est pourquoi les clones d’une plateforme bien connue proposés par courtier ont été une voie difficile pendant des années. La défense consiste à montrer que votre application fait des choses que la version générique ne fait pas, ce qui constitue une raison supplémentaire de construire l’espace compte plutôt qu’un autre écran de graphiques.
• Directive 4.2 vise les applications trop légères. Si votre soumission est simplement une coquille de web view autour de votre portail client, sans rien de natif, attendez-vous à devoir expliquer ce qu’apporte l’application par rapport au site mobile. La capture de documents par caméra, la connexion biométrique et les notifications push sont les réponses habituelles, et elles doivent être présentes avant la soumission plutôt que promises dans les notes de revue.
• Directive 5.1.1 exige une politique de confidentialité indiquant ce que vous collectez, comment vous l’utilisez, à qui vous le communiquez et comment un utilisateur supprime ses données. Apple attend aussi que la suppression du compte soit disponible dans l’application. Pour un broker réglementé soumis à des obligations de conservation des données, il faut une réponse sérieuse, généralement la suppression du compte de l’application ainsi qu’une déclaration claire sur ce qui doit être conservé par la loi et pendant combien de temps.

Deux points pratiques qui raccourcissent la revue : donnez au relecteur des identifiants de démonstration valides sur un compte disposant de fonds et de positions ouvertes, et joignez un court enregistrement vidéo du parcours. Les relecteurs qui ne peuvent pas franchir votre verrou KYC rejetteront plutôt que d’enquêter.

La question de l’achat in-app pour les Prop Firm

Les Prop Firm ont un problème supplémentaire. La directive 3.1.1 exige l’achat in-app pour débloquer des fonctionnalités ou du contenu, et exclut explicitement l’utilisation de votre propre mécanisme pour cela. La question de savoir si des frais de challenge relèvent du contenu numérique est une question à trancher avant de construire le flux, et non après, car la différence de commission est suffisamment importante pour modifier votre économie unitaire.

Le schéma le plus sûr, adopté par la plupart des opérateurs, consiste à conserver les achats de challenges sur le web et à laisser l’application afficher et gérer les comptes que le trader possède déjà. Les règles d’Apple concernant les liens vers des achats externes ont changé plusieurs fois ces dernières années et varient selon les régions, donc lisez le texte actuel de la directive plutôt qu’un article de blog vieux de deux ans, celui-ci compris.

Array

Array

Array

ArrayArrayArray

Array

Array

ArrayArrayArray

Array

Array

Array

Array