Systèmes de négociation
Organisez l’état d’exécution, la fraîcheur des données, les décisions, les ordres, les positions, les contrôles et les incidents dans une vue opérationnelle claire.
Comment le flux de travail s’articule
Les graphiques peuvent situer le marché, mais l’exploitation d’un logiciel automatisé exige une autre hiérarchie d’information. La vue principale nécessite l'état d'exécution actuel, la connectivité, la fraîcheur des données, les décisions récentes, la progression des ordres, les contrôles et les incidents non résolus. Ensemble, ces éléments donnent aux opérateurs les éléments de preuve dont ils ont besoin pour comprendre et gérer le flux de travail sans suggérer un rendement financier.
Afficher le papier, la démo ou l'environnement en direct; courir, faire une pause, s'arrêter ou arrêter l'état; l'état en direct; la version déployée; le dernier battement de cœur; et le nombre d'incidents actifs. Ces détails indiquent si le système est autorisé et capable d'agir avant qu'une personne interprète des cartes ou des statistiques.
Affichez le dernier temps de données du marché, la connexion source, la cadence attendue et le seuil de données statiques. Une évaluation récente de la stratégie fondée sur de vieux commentaires ne devrait pas sembler saine. Liener chaque décision aux timestamps d'entrée, à la version des règles, au résultat et au code de raison.
Le groupe a demandé, soumis, accepté, ouvert, partiellement rempli, rempli, annulé, rejeté et les dossiers incertains avec les identifiants des courtiers et les temps de mise à jour. Montrez l'état local et l'état déclaré par les courtiers quand ils diffèrent. Les positions devraient être liées aux exécutions qui les ont créées là où les données du courtier appuient cette relation.
Pause, reprise, annulation et actions d'urgence ont besoin de contrôles de rôle, confirmation de la portée, un changement d'état côté serveur, et un résultat visible. Les incidents devraient identifier les stratégies ou les liens touchés, le propriétaire, l'accusé de réception, les notes de recouvrement et si le rapprochement est terminé.
Une demande de commande prend fin après la soumission. Le tableau de bord doit montrer la stratégie et l'état du système, l'ID de commande du client, la connexion du courtier, le dernier événement confirmé et un résultat de soumission inconnu. Il ne devrait pas afficher échoué simplement parce que la réponse n'a pas été reçue. L'opérateur a besoin d'une recherche contrôlée ou d'une action de rapprochement avant qu'une autre soumission ne soit possible.
Si le courtier déclare une commande ouverte, le dossier local est relié à cette commande et continue tout au long de son cycle de vie. Si aucune commande n'est trouvée après les vérifications définies, l'exploitant autorisé peut décider si la demande est sûre de réessayer. L'historique de l'incident conserve le délai, les questions, l'état de courtier observé, la décision, et le règlement éventuel.
Repère visuel
Le premier écran prend en charge les décisions d'exploitation rapides tout en conservant un chemin vers les événements derrière chaque statut.
État de fonctionnement
Mode, stratégies activées, état de pause et santé de connexion.
Fraise
Dernier marché, compte, commande et mise à jour des battements de coeur avec la source.
Cycle de vie des commandes
État demandé, accepté, ouvert, partiel, terminal et incertain.
Exceptions
Rejeté, abandonné, déconnecté, dupliqué et travail de rapprochement.
Contrôles
Arrêt autorisé, reprise, annulation, reconnaissance et mesures de récupération.
Preuves
Tracer les identifiants, les charges utiles, les tentatives, les décisions et l'historique de la vérification.
La surveillance de l'accès, de la configuration de la stratégie, de l'activation en direct, de l'annulation de la commande et de la fermeture des incidents ne devrait pas automatiquement avoir le même rôle. Définir les actions qui nécessitent une réauthentification, une deuxième approbation, une raison ou une fenêtre de maintenance. Les commandes doivent appeler le même flux de travail protégé que toute action automatisée; un bouton de tableau de bord n'est pas un raccourci autour des règles d'état.
Décider qui consulte le tableau de bord au démarrage, pendant l'opération, après une alerte et au moment du transfert. Les routines utiles comprennent la vérification de la fraîcheur des données avant l'activation, l'examen des écarts non résolus, la confirmation de la prise en charge de l’alerte et l'enregistrement des changements de configuration. Tester les écrans étroits et les états dégradés afin que les contrôles critiques ne disparaissent pas lorsque le système est soumis à des contraintes.
Questions pratiques
Il peut être pertinent pour un opérateur autorisé, mais il ne remplace pas le temps d'exécution, la connectivité, l'état d'ordre, le contrôle et la visibilité d'incident nécessaire pour faire fonctionner le logiciel.
Non. L'interface doit confirmer l'état de l'application et afficher séparément l'état du courtier ou de la plateforme. Les ordres et les positions ouverts peuvent exiger leurs propres actions et rapprochement.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Sun Cluster construit des systèmes de négociation privés avec des règles définies par le client, des tableaux de bord opérationnels, l'intégration des courtiers et la surveillance.
