Systèmes de négociation
Créez une matrice de tests couvrant les symboles, la précision, les minimums, la taille des contrats, les types d’ordres et l’arrondissement avant de partager une stratégie entre plateformes.
Comment le flux de travail s’articule
Deux plateformes peuvent désigner le même marché en utilisant différents symboles, unités de quantité, incréments de prix, règles minimales de commande et définitions de contrats dérivés. Une matrice de test de normalisation vérifie ces limites au niveau du connecteur afin que la logique de flux de travail partagée ne devine pas.
Représenter séparément le lieu, le type de marché, l'actif de base, l'actif de soumission, l'actif de règlement, l'expiration et la variante du contrat. Carter le symbole et l'identificateur de l'échange à cet enregistrement. Ne pas déduire que le texte identique décrit un règlement ou un comportement contractuel identiques.
Déterminer si la quantité représente les unités de base, la valeur des devis, les lots ou les contrats et si la taille du contrat change le montant économique. Appliquer ensuite la taille de l'étape, la coche de prix, la quantité minimale et les règles théoriques minimales à partir des métadonnées actuelles.
Pour chaque marché pris en charge, tester les valeurs ci-dessous, les valeurs égales et supérieures aux minimums; les valeurs nécessitant un arrondi; les types de commandes non disponibles; les instruments radiés ou inactifs; et les métadonnées mises à jour. Enregistrer la demande normalisée ou la raison de rejet attendue.
Les tests devraient utiliser des boîtes à sable ou des paramètres de validation documentés lorsqu'ils sont disponibles et ne devraient jamais supposer qu'une vérification réussie du format établit un résultat financier.
Si les métadonnées sont manquantes, dépassées ou incompatibles avec le type de marché configuré, empêcher la soumission et créer une alerte opérationnelle. Enregistrez les valeurs internes, la version des métadonnées, la transformation et les paramètres finals de la plateforme pour un examen ultérieur.
Choisissez un petit ensemble d'instruments et enregistrez l'identificateur de chaque plateforme, les actifs de base et de soumission, le type de marché, l'unité de quantité, l'augmentation de prix, l'augmentation de quantité, la taille minimale, le cas échéant, et les capacités de commande prises en charge. Gardez la version de documentation source et le contexte de compte parce que les permissions et les types de produits peuvent différer.
Les essais doivent porter sur la conversion dans les deux sens. Une intention d'ordre interne devient une demande de lieu, et une réponse de lieu devient un événement interne sans perdre les valeurs de source. Utiliser la manipulation décimale exacte appropriée à l'intégration; l'arrondi binaire du point flottant peut produire une quantité qui apparaît valide localement mais viole l'accroissement de la plateforme.
| Affaire | Entrée | Traitement prévu |
|---|---|---|
| Paire connue | Instrument interne et quantité de base | Traduire l'identifiant et valider les incréments |
| Quantité inférieure au minimum | Précision valide, taille insuffisante | Rejet avant présentation avec règle nommée |
| Excédent de décimales | Quantité non alignée à l'étape | Appliquer une politique d'arrondissement documentée ou rejeter |
| Symbole de lieu inconnu | Pas de cartographie d'identité active | Échec fermé et besoin d'un examen cartographique |
| Inadéquation du type de marché | Spot intention contre la cartographie dérivée | Rejet comme instrument incompatible |
Les lieux peuvent ajouter, supprimer, suspendre ou modifier des règles d'instrument. Enregistrez lorsque les métadonnées ont été récupérées, validez-les avant d'activer l'instrument, et affichez clairement un état bloqué lorsque la cartographie devient inexistante ou incompatible. Ne choisissez pas silencieusement un marché du même nom.
Exécuter des tests contractuels contre les appareils du fournisseur sauvegardés et des vérifications planifiées par rapport aux paramètres d'essai autorisés, le cas échéant. Inclure zéro, négatif, minimum-moins-une-étape, exactement minimum, très grandes valeurs, et les parcours aller-retour de conversion. Un essai de normalisation échoué devrait empêcher la construction de la demande et identifier l'instrument, le plateforme, le champ, la règle source et la version de configuration.
Repère visuel
Le texte symbolique à lui seul ne suffit pas; identité, type de marché, unités, incréments, capacités et fraîcheur toute matière.
Identité interne
Instruments stables et représentation de type marché.
Identité de la plateforme
Symbole documenté ou ID instrument pour la connexion.
Unités
Base, devis, contrats, taille du lot et règles de conversion.
Précision
Tique de prix, étape de quantité, minimums, et politique d'arrondi.
Capacités
Types de commandes pris en charge, politiques de temps et contraintes de compte.
État des métadonnées
Source, temps de récupération, version et état de suspension.
Questions pratiques
Ils peuvent exposer les métadonnées et les méthodes communes, mais l'application a encore besoin d'une unité approuvée, d'un arrondi, d'un type de marché et d'une politique d'échec plus des tests pour chaque plateforme pris en charge.
Choisir une cadence en fonction du comportement de la plateforme et du risque de flux de travail, actualiser les rejets pertinents et bloquer la soumission lorsque les métadonnées requises sont trop anciennes ou indisponibles.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Sun Cluster développe l'automatisation des transactions cryptographiques avec des connecteurs spécifiques au site, des contrôles définis par le client, des environnements de test et une surveillance opérationnelle.
