Certificación

PTP-FIX API

V1.1
Historia del documento

Fecha Versión Descripción Autor

23/11/2015 1.0  Versión Inicial Primary
10/04/2018 1.1  Se actualizan casos de prueba Primary

1
Índice
Historia del documento ................................................................................................................... 1
Script de Certificación PTP-FIX API ................................................................................................ 3
Objetivo ....................................................................................................................................... 3
Metodología de prueba................................................................................................................ 3
Documentación PTP-FIX API ...................................................................................................... 3
Datos Certificación ...................................................................................................................... 3
Características y Mensajes a certificar ........................................................................................ 4
Casos de Prueba ......................................................................................................................... 5
Otras preguntas ........................................................................................................................... 6
Resultados de las pruebas .......................................................................................................... 7

2
 Script de Certificación PTP-FIX API
Objetivo
El objetivo de este documento es detallar los pasos necesarios para certificar el correcto funcionamiento
de aplicaciones que utilicen la interfaz FIX de PTP (Primary Trading Platform).

El ISV deberá pasar con éxito los casos de prueba asociados a la funcionalidad a homologar (conexión,
order managment, market data, etc) para obtener la certificación correspondiente.

Metodología de prueba
Para comprobar la correcta implementación del Software del ISV se realizaran una serie de pruebas
sobre dicha aplicación. La idea es poder corroborar que las funcionalidades de la API y los datos
enviados/recibidos desde/hacia la API funcionen correctamente.

Al momento de certificar se comunicaran al ISV los valores a usar en los casos de prueba descriptos más
adelante.

Documentación PTP-FIX API

Documentación de la API disponible en: http//[Link]

Datos Certificación
Plataforma

Versión FIX
ISV
Contacto ISV
Contacto Primary
Versión PTP-FIX API
Alcance
Fecha Certificación
Resultado

3
Características y Mensajes a certificar
Tipo de Soportado/C
Mensaje Comentarios
Mensaje ertificable?
Logon (MsgType=A) YES
Heartbeat (MsgType=0) YES YES
Reject – Session Level
YES
Session (MsgType = 3)
Sequence Reset
YES
(MsgType=4)
Logout (MsgType=5) YES
News (MsgType=B) NO
Common Business Message Reject
NO
(MsgType=j)
New Order – Single
NO
(MsgType=D)
Order Cancel Request
NO
(MsgType=F)
Order Cancel/Replace
NO
Request (MsgType=G)
Order Cancel Reject
NO
(MsgType=9)
Order Mass Status Request
NO
(MsgType=AF)
Order Mass Cancel Request
NO
(MsgType=q)
Execution Report : New
NO
(MsgType=8)
Execution Report: Order
Order Canceled Response NO
Management (MsgType=8)
Execution Report: Order
Replaced Response NO
(MsgType=8)
Execution Report: Order
Filled/Partially Filled NO
(MsgType=8)
Execution Report : Order
Status Response – No Orders NO
(MsgType=8)
Execution Report
(MsgType=8): Order Status NO
Response – With Orders
Execution Report : Reject
Message Response NO
(MsgType=8)

4
 Market Data Request
YES
(MsgType=V)
Market Data Snapshot / Full
Market Data YES
Refresh (MsgType=W)
Market Data Request Reject
YES
(MsgType=Y)
Security List Request Only for FIX 5.0sp2 certifications
Security YES
(MsgType=x)
Definition Security List (MsgType=y) YES Only for FIX 5.0sp2 certifications

5
Casos de Prueba
Logon (MsgType=A):
Specific tags to fill:
 SenderCompID:
 TargetCompID: EXEC
 HeartBeat Interval: 30
 User:
 Password: xxxxxxxxx
Caso 1
Session  BeginString: FIXT.1.1
(MsgTypes=A, 4, 5) Disconnection Request (MsgType=5):
Specific tags to fill: N/A
Sequence number request (MsgType=4):
Specific tags to fill: N/A
Wrong sequence number request
(MsgType=4):
Specific tags to fill: N/A
Security List Request (MsgType=x):
Request for all securities:
Tags to fill: 559 with value 4.
Security Definition Security Status Request (MsgType = e):
Caso 2
(MsgTypes= x, e) Request different Subscription Type for all or specific
security:
Tags to fill: 263 and 55 to be defined during the
certification process.
Market Data Request (MsgType=V)
Tags to fill:
Securities subscription (tag 55); Subscription types
Market Data (tag 263); Market Depth (tag 264); Update Type
Caso 3
(MsgTypes=V)
(tag 265); MD EntryTypes (tag 269).
Values to use: to be defined during the certification
process
New Order – Single (MsgType=D):
Tags to fill:
TimeInForce (tag 59): DAY, IOC, GTD, FOK, GTC.
Side (tag 54): Buy, Sell.
OrdType (tag 40): Limit, MarketToLimit.
Products: All or None products could be required.
Order Management Example: DOMar19A
Caso 4
(MsgTypes=D,F,G,9,AF,q,8)
CancelPrevious: Use CancelPrevious?

Order Cancel Request (MsgType=F):

Values to use: to be defined during the certification
process

6
 Wrong order Cancel Request (MsgType=F)
Tags to fill:
Client Order Id (tag 11): Wrong ClOrdId.

Order Cancel/Replace Request (MsgType=G):

Values to use: to be defined during the certification
process

Wrong Cancel/Replace Request (MsgType=G):

Tags to fill:
Client Order Id (tag 11): Wrong ClOrdId.
Order Cancel Reject (MsgType=9)
Order Status Request (MsgType = H):
Values to use: to be defined during the certification
process
Order Mass Status Request (MsgType=AF):
Values to use: to be defined during the certification
process
Order Mass Cancel Request (MsgType=q):
Values to use: to be defined during the certification
process
Execution Report (MsgType=8):
Execution Types to test:
 New
 Order Canceled Response
 Order Replaced Response
 Order Filled/Partially Filled
 Order Status Response – No Orders
 Order Status Response – With Orders
 Reject Message Response
Market and Trading
Caso 5 Session Status Trading Session Status (MsgType = h)
(MsgType=h)

7
Otras preguntas

 Horarios de conexion?
 Uso de SSL?
 Engine usado / version / lenguaje?
 IPs desde las que se conectara?
 Screenshots?
 Redundancia?
 Contribuye ofertas al Store?
 Control de Riesgo?
 Se integra con Sistemas de Back Office?
 Implementa Cancel On Disconnect ?

8
Resultados de las pruebas
#Test Nombre Descripción Resultado Esperado Resultado Obtenido

1.1 Pedido de conexión Se pedirá al cliente realizar un pedido de conexión. Cliente conectado correctamente.
Se pedirá al cliente realizar un pedido de
1.2 Pedido de desconexión Cliente desconectado correctamente.
desconexión.
Se pedirá al cliente realizar un pedido del número de El número de secuencia es devuelto y
1.3 Pedido número de secuencia
secuencia. procesado correctamente por la aplicación.
Se pedirá al cliente realizar un pedido para obtener La aplicación recibe y procesa correctamente
2.1 Listar todas las Securities
una lista de todas las securities disponibles. la lista de securities recibida del mercado.
Se pedirá al cliente realizar un pedido para obtener el La aplicación recibe y procesa correctamente
2.2 Pedir Security Status
estado de una security. el estado de la security.
Se pedirá al cliente realizar un request para
Todos los pedidos de suscripción a MD son
Suscripción a Market Data suscribirse a MD con distintas Securities,
3.1 correctos para todas las alternativas
para una Security profundidad de mercado, tipos de suscripción, tipos
propuestas.
de actualización y varios entry types.
4.1 Nueva Orden El cliente deberá mandar una orden nueva. La orden se crea correctamente.
Se pedirá al cliente mandar un mensaje para cancelar
4.2 Cancelar una Orden La orden se cancela correctamente.
una orden.
Reemplazar una Orden Se pedirá al cliente mandar un mensaje para cambiar
4.3 La orden se modifica correctamente.
existente los parámetros de una orden existente.
Se pedirá al cliente mandar un mensaje para cambiar El mensaje de rechazo de orden reemplazada
Reemplazar incorrectamente
4.4 los parámetros de una orden existente es recibido y procesado correctamente por la
una orden
incorrectamente. aplicación.
Verificar mensaje Order El mensaje de rechazo de orden cancelada es
Verificar que se reciba correctamente el mensaje de
4.5 recibido y procesado correctamente por la
Cancel Reject Order Cancel Reject (MsgType=9)
aplicación.
El pedido del estado de una orden es enviado
4.6 Pedir el estado de una orden El cliente deberá pedir el estado de una orden. correctamente y la respuesta es recibida y
procesada correctamente.
El pedido del estado de las órdenes es enviado
Pedir el Estado de Varias El cliente deberá pedir el estado de todas las órdenes
4.7 correctamente y la respuesta es recibida y
Ordenes que cumplan con los criterios definidos.
procesada correctamente por la aplicación.
Cancelación de varias El cliente deberá enviar un pedido de cancelación
Todas las órdenes son canceladas
4.8 masiva de órdenes que cumplan con criterios
Ordenes correctamente.
definidos durante el proceso.
Se deberá verificar que los mensajes de Execution
Report enviados por el mercado al cliente sean
correctos.
Corroborar los siguientes tipos de mensajes:
Verificar mensajes Execution  New Todos los mensajes Execution Report son
4.9 Report Messages  Order Canceled Response recibidos y procesados correctamente por la
 Order Replaced Response aplicación.
 Order Filled/Partially Filled
 Order Status Response – No Orders
 Order Status Response – With Orders
 Reject Message Response
La aplicación del cliente deberá poder recibir y Los mensajes del tipo Trading Session Status
Verificar Mensajes del tipo
5.1 procesar los mensajes sobre el estado de la sesión de son recibidos y procesados correctamente por
Trading Session Status
trading enviados por el mercado. la aplicación.