RESOLUCIÓN 03736 DE 2024
(octubre 4)
Diario Oficial No. 52.899 de 4 de octubre de 2024
MINISTERIO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES
Por la cual se establecen obligaciones de reporte de información de la operación de giros postales de pago y riesgo operativo a cargo de los Operadores Postales de Pago y se deroga la Resolución número 1758 de 2020 y sus Anexos.
EL MINISTRO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES,
en ejercicio de sus facultades legales, en especial las que le confiere el artículo 5o del Decreto número 1064 de 2020, y
CONSIDERANDO QUE:
A través de la Resolución número 1758 de 2020, el Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC) estandarizó y fijó “(…) el proceso de reporte que deben seguir los operadores postales de pago al remitir la información relacionada con las operaciones postales de pago realizadas a través de los diferentes canales de distribución autorizados, así como la forma en que deben reportar los riesgos operativos identificados, medidos, controlados y monitoreados en el desarrollo de la operación postal de pago, que permita evidenciar el cumplimiento del Sistema de Administración de Riesgo Operativo (SARO) en el sector postal de pago. (…)”.
En el parágrafo del artículo 1o de la resolución referida, se estableció que, para cumplir con el objeto citado, se pondría en marcha una plataforma de transmisión de información (repositorio de información de la operación postal de pago) por parte de los operadores de servicios postales de pago, haciendo uso del servicio web dispuesto por el Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC).
En ese sentido, el reporte de la información por parte de los operadores de servicios postales de pago, haciendo uso del servicio web dispuesto por este Ministerio, se ha desarrollado bajo la estructura y las condiciones definidas en la Resolución número 1758 de 2020, específicamente bajo lo dispuesto en los Anexos denominados Reporte diario operación postal de pago VF y Reporte Matriz de Riesgo Operativo VF.
En el ejercicio de dicho reporte, por parte de este Ministerio se detectó que el servicio web a través del cual se realizan los procesos de captura, validación, cifrado y transmisión de la información de la operación postal de pago: (i) no cuenta con la estructura suficiente para la recepción de información que debe reportar el operador de pago frente a los giros postales, (ii) presenta una obsolescencia tecnológica lo que conlleva a tener riesgos de seguridad, compatibilidad y gestión de los datos reportados, (iii) se vio la necesidad de incorporar los diferentes modelos de negocio del mercado según la modalidad de prestación del servicio y (iv) siendo los operadores postales de pago los principales usuarios del servicio web mencionado, se presentan dificultades al momento de la transmisión de información de los giros postales y recepción por parte del servicio web, ante la ausencia de reglas de validación para garantizar la integridad de los datos, tanto para los operadores que la transmiten como para la entidad que la recolecta.
Así las cosas y tomando como base las falencias detectadas, fue necesaria la reestructuración del servicio web mediante la implementación de un mecanismo tecnológico que contemplara las diferentes acciones de mejora para satisfacer las necesidades de recolección, análisis y uso de la data de giros postales, integrando la cadena de valor del servicio de giro postal de pago respecto del mecanismo de recolección de data dispuesto por el MinTIC.
En virtud de lo anterior, y en aras de continuar con el óptimo ejercicio de las funciones que en materia de inspección, vigilancia y control tiene a cargo el Ministerio de Tecnologías de la Información y las Comunicaciones sobre los operadores de servicios postales de pago, se celebró entre el Fondo Único de Tecnologías de la Información y las Comunicaciones y la sociedad TRUST & LEGAL SAS el Contrato número 788 de 2023, cuyo objeto es:
“(…) Diseñar, estandarizar e implementar la plataforma de transmisión y consumo de datos del servicio de giros postales de pago y de los riesgos operativos para el proceso de reporte relacionada con las operaciones de giros postales de pago realizadas a través de los diferentes canales de distribución autorizados que deben efectuar los operadores habilitados para prestar el servicio.(…)”.
En el marco del contrato señalado y como parte de sus entregables, en cumplimiento de sus obligaciones, el contratista elaboró manuales para el correcto uso del servicio web comentado, los cuales para efectos de la presente resolución se unifican en un solo documento denominado: Manual Operador Postal de Pago.
En ese sentido, se consolida en un único Anexo el lineamiento respecto de la obligación de reporte de la información del servicio de giros postales de pago y de los riesgos operativos, detallando los campos y variables esperados según las modalidades de prestación del servicio. Este documento permitirá a los operadores adaptar sus sistemas para realizar los procesos de reporte en línea y así dar cumplimiento a lo establecido en la presente resolución.
Teniendo en cuenta lo expuesto, y conforme con el contrato celebrado, el Ministerio cuenta con un servicio web que permite administrar el acceso para consumo, tanto de los operadores autorizados para prestar el servicio de giros postales de pago que deben cumplir con las obligaciones de reporte de la información referente a su operación, como de las áreas funcionales de esta entidad que vayan a tener acceso a los datos, implementando reglas de validación de confidencialidad, integridad, disponibilidad, autenticidad, privacidad y no repudio de la información en la información reportada, atributos que no se encontraban desarrollados en el servicio web implementado inicialmente para esta finalidad mediante la Resolución MinTIC 1758 de 2020 y sus Anexos.
Conforme con lo señalado, es necesario reglamentar las obligaciones de reporte de información de la operación de giros postales de pago y de riesgo operativo a cargo de los Operadores Postales de Pago, considerando que a partir de la configuración del servicio web existente se realizó un nuevo despliegue con mejoras tecnológicas, incluyendo reglas de negocio, que subsana las deficiencias que fueron detectadas y así robustecer el proceso de transmisión de información, implementando las acciones para satisfacer las necesidades de recolección, análisis y uso de la data de giros postales y, en consecuencia, derogar la Resolución MinTIC 1758 de 2020 y sus Anexos.
En virtud de lo establecido en el artículo 2.2.2.30.5., del Decreto número 1074 de 2015, el Ministerio de Tecnologías de la Información y las Comunicaciones diligenció el cuestionario expedido por la Superintendencia de Industria y Comercio (SIC) mediante el artículo 5o de la Resolución SIC 44649 de 2010, con el fin de verificar si las disposiciones contempladas en el presente acto administrativo tienen alguna incidencia en la libre competencia. Dado que la totalidad de las respuestas al cuestionario “Evaluación de la incidencia sobre la libre competencia de los proyectos de actos administrativos expedidos con fines regulatorios” fueron negativas, el presente acto administrativo no plantea una restricción indebida a la libre competencia, motivo por el cual no resultó necesario remitir la propuesta regulatoria a la SIC de conformidad con lo dispuesto en el numeral 1 del artículo 2.2.2.30.6 del Decreto número 1074 de 2015.
De conformidad con lo previsto en el artículo 1.3.1 de la Resolución número 1857 de 2023, por la cual se adoptan e imparten directrices sobre producción normativa del Ministerio de Tecnologías de la Información y las Comunicaciones (…), las normas de que trata la presente Resolución fueron publicadas en la sede electrónica del Ministerio de Tecnologías de la Información y las Comunicaciones durante el período del 15 al 29 de julio de 2024 con el fin de recibir opiniones, sugerencias o propuestas alternativas por parte de los ciudadanos y grupos de interés.
En mérito de lo expuesto,
RESUELVE:
ARTÍCULO 1o. OBJETO. La presente resolución tiene por objeto estandarizar y fijar el proceso de reporte de información que deben seguir los operadores postales de pago al remitir la información relacionada con las operaciones postales de pago realizadas a través de los diferentes canales de distribución autorizados; así como, la forma en que deben reportar los riesgos operativos identificados, medidos, controlados y monitoreados en el desarrollo de la operación postal de pago, que permita evidenciar el cumplimiento del Sistema de Administración de Riesgo Operativo (SARO) en el sector postal de pago.
El anexo denominado “Manual operador postal de pago” hace parte integral de la presente resolución y podrá ser actualizado, aclarado o modificado cuando la necesidad o la ley así lo requieran.
PARÁGRAFO. Para el cumplimiento de lo previsto en el presente artículo, el operador postal habilitado deberá implementar los mecanismos y recursos tecnológicos necesarios para acceder al servicio web dispuesto por el Ministerio de Tecnologías de la Información y las Comunicaciones y así transmitir la información pertinente a la operación relacionada con el servicio postal de pago.
ARTÍCULO 2o. SUJETOS OBLIGADOS. Las obligaciones establecidas en esta resolución se encuentran a cargo de los operadores postales de pago habilitados por el Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC), así como del operador postal o concesionario de correo oficial en cuanto a las actividades que desarrolla en materia de giros internacionales. De la misma manera, los operadores postales de pago habilitados están sujetos a realizar el reporte de sus colaboradores empresariales.
ARTÍCULO 3o. DEFINICIONES. Para los efectos de la presente resolución se adoptan las siguientes definiciones:
1. API: Interfaz de programación de aplicaciones, son un medio simplificado para conectar infraestructura a través del desarrollo de aplicaciones, también permiten compartir datos.
2. Autenticación: Procedimiento informático que permite asegurar que un usuario de un sitio web u otro servicio similar es auténtico o quien dice ser.
3. Canales de distribución de los servicios postales de pago: Cualquier medio, previamente autorizado por el Ministerio de Tecnologías de la Información y las Comunicaciones, que permita al usuario interactuar con el operador postal de pago para atender la necesidad de realizar una operación postal de pago, tales como puntos de atención al público, dispositivos y medios tecnológicos.
4. Colaborador empresarial: Para efectos del presente documento se entenderá como colaborador empresarial definido en el artículo 3o de la Resolución Min- TIC 1292 de 2021, o la norma que la modifique, aclare o subrogue, esto es, las personas naturales o jurídicas que disponen de puntos de atención al público, con las cuales el Operador de Servicios Postales de Pago realiza un contrato, para ofrecer sus servicios a través de una red o grupo de redes.
5. Giro en efectivo: Servicio mediante el cual se ordenan pagos a personas naturales o jurídicas por cuenta de otras, en el territorio nacional, a través de una red postal.
La modalidad de envío podrá ser entre otras, física o electrónica.
6. JWT (JSON Web Token, por su sigla en inglés): La autenticación basada en token es una referencia en el desarrollo de aplicaciones web, ya que presenta algunas ventajas respecto a la autenticación más común, en la que se guardan en sesión los datos del usuario. En la autenticación con token, el usuario se identifica bien con un usuario/contraseña o mediante una única clave y la aplicación web le devuelve una especie de firma cifrada que el usuario usará en las cabeceras de cada una de las peticiones HTTP. Esta información no se tiene que almacenar en la parte del servidor, como en el caso de la autenticación a través de sesión, sino que se guarda en la parte del cliente y es la aplicación la que comprobará si es válida en cada una de las peticiones.
7. Plataforma de transmisión de información de operación postal de pago (Repositorio de información de la operación postal de pago): Es el sistema de reporte de información que accede al servicio web dispuesto por el Ministerio de Tecnologías de la Información y las Comunicaciones, para que los operadores postales de pago remitan a esta entidad el detalle de la operación postal de pago.
8. Servicio web MINTIC: Mecanismo sistematizado de recepción de información del Ministerio de Tecnología de la Información y las Comunicaciones, a través del cual se genera la transmisión, captura, validación y cifrado de la información de la operación postal de pago por parte de los operadores habilitados por el Ministerio para prestar el servicio postal de pago.
9. Transacciones en efectivo: Según el artículo 3o, de la Resolución MinTIC 2679 de 2016: Todas las transacciones que en desarrollo del giro ordinario de sus negocios realice el sujeto obligado y que involucren pagos mediante entrega o recibo de dinero en efectivo de billetes y monedas de denominación nacional. Se entenderán también como transacciones en efectivo los pagos que involucren la entrega o recibo de divisas y su monetización y que se realicen mediante la modalidad de giros internacionales realizados por el Operador Postal Oficial, en los términos del numeral 2.2.2 del artículo 3o de la Ley 1369 de 2009, en concordancia con la Ley 9ª de 1991.
ARTÍCULO 4o. REPORTE DE INFORMACIÓN AL MINISTERIO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES. Los operadores postales de pago habilitados para prestar el servicio, deben remitir al Ministerio de Tecnologías de la Información y las Comunicaciones la información correspondiente a las operaciones postales de pago cursadas en sus diferentes canales de distribución, bajo la estructura y demás condiciones especificadas en la presente resolución y su anexo. De la misma manera, los operadores habilitados están sujetos a realizar el reporte de sus colaboradores empresariales, tal como se determina en el artículo 2o de la presente resolución.
4.1. Reporte operación postal de pago
4.1.1. Reporte de operación en línea
Para efectos de la operación en línea (transacciones de operaciones postales de pago), el procedimiento informático y tecnológico del reporte de las transacciones de operaciones postales de pago cursadas en los diferentes canales de distribución de servicios postales de pago, debe efectuarse a través de una plataforma de transmisión de información, desarrollada por el operador postal de pago, que permite transmitir de manera inmediata la operación postal de pago realizada, mediante el servicio web desarrollado y dispuesto por el Ministerio de Tecnologías de la Información y las Comunicaciones, de acuerdo con el Anexo (Manual operador postal de pago) de la presente resolución. Esto supone que la transacción correspondiente no debe ser almacenada ni procesada por parte del operador postal de pago previo al envío al Ministerio de Tecnologías de la Información y las Comunicaciones. Lo anterior, sin perjuicio de las obligaciones de suministro, recuperación y reporte de información establecidas en la normativa aplicable.
4.1.2. Reporte al cierre de la operación postal
Cuando el operador postal de pago no pueda realizar el reporte en línea, debe consolidar la información de su operación postal de pago una vez culminadas las transacciones en efectivo realizadas durante el día en los diferentes canales de distribución de servicios postales de pago y trasmitirla de acuerdo con la estructura establecida por el Ministerio de Tecnologías de la Información y las Comunicaciones. Este reporte deberá ser entregado antes de finalizar el día de la operación.
El Ministerio de Tecnologías de la Información y las Comunicaciones brindará la información técnica necesaria para la implementación de las plataformas de transmisión de información, requeridas para el cumplimiento de los reportes de información de los operadores postales de pago. El desarrollo de los mecanismos de transmisión de información estará a cargo del operador postal de pago quien debe garantizar la transmisión cumpliendo con los mecanismos establecidos en la presente resolución.
4.1.3 Contingencias en el reporte de la operación postal de pago.
En caso de que el operador postal de pago no pueda transmitir la información al cierre de la operación, deberá informar y justificarlo al Ministerio de Tecnologías de la Información y las Comunicaciones. El reporte del incidente deberá realizarlo a más tardar el día hábil siguiente a su materialización y los soportes del incidente se remitirán máximo al tercer día hábil siguiente de su ocurrencia. Tanto la información del incidente como los respectivos soportes se enviarán a través del correo electrónico habilitado por el MinTIC para el efecto. El sistema detectará los reportes que se realicen fuera de las fechas de cada jornada y los etiquetará como extemporáneos.
En caso de que el operador postal de pago presente una falla en la transmisión deberá justificar y evidenciar la imposibilidad del reporte, sin perjuicio de que el Ministerio de Tecnologías de la Información y las Comunicaciones pueda iniciar una investigación administrativa en el marco de lo establecido en la Ley 1369 de 2009 que regula la operación postal, o las normas, que la modifique, adicione o sustituya.
En caso de que se presenten fallas imputables a los sistemas del Ministerio, el operador postal de pago pondrá los archivos en un protocolo de transferencia segura de archivos (SFTP por sus siglas en inglés) sobre su infraestructura, junto con las credenciales para acceder a la información a través del correo electrónico mesadeserviciosectorial@mintic.gov.co o el canal que disponga el Ministerio, considerando que a través de la Mesa de Servicio sectorial se atenderán los requerimientos para el soporte.
La información debe estar en archivos planos, de acuerdo con la estructura establecida en el Anexo (Manual operador postal de pago) de la presente resolución.
4.2. Reporte base de datos de riesgos operativos
Corresponde al registro de los riesgos operativos identificados, medidos, controlados y monitoreados por parte del operador postal de pago, de acuerdo con el formato establecido en el Anexo (Manual operador postal de pago) de la presente resolución. La información deberá ser remitida semestralmente al Ministerio de Tecnologías de la Información y las Comunicaciones por medio de servicio web dispuesto por esta entidad, dentro de los quince (15) días calendario del mes siguiente al período reportado.
ARTÍCULO 5o. LINEAMIENTOS DE REPORTE. Los reportes de que trata la presente resolución y su anexo deberán efectuarse atendiendo los lineamientos técnicos que sobre el particular establezca el Ministerio de Tecnologías de la Información y las Comunicaciones, a través de su Oficina de Tecnologías de la Información.
PARÁGRAFO. La estructura que debe ser utilizada por parte de los operadores postales de pago, en lo relacionado con las transacciones diarias y lo relacionado a la base de datos de riesgos operativos, se encuentra establecida en el Anexo (Manual operador postal de pago), que forma parte integral de la presente resolución.
ARTÍCULO 6o. SEGURIDAD Y PRIVACIDAD DE LA INFORMACIÓN. La información suministrada por los operadores postales deberá contar con los controles de seguridad y privacidad de la información establecidos mediante la Resolución MinTIC 2239 de 2024 y aquellas que la adicionen, modifiquen o subroguen.
PARÁGRAFO 1o. La información suministrada por los operadores postales de pago referente a los servicios postales de pago será tratada de acuerdo con la Resolución número 924 de 2020, mediante la cual se actualiza la Política de Tratamiento de Datos Personales, en los términos previstos en las Leyes 1266 de 2008 y 1581 de 2012, o por la norma que la adicione, modifique o subrogue.
ARTÍCULO 7o. IMPLEMENTACIÓN. Los operadores postales de pago contarán con un término de un (1) mes, que inicia a partir de la entrada en vigor del presente acto administrativo, para que ajusten y actualicen sus sistemas de información, de acuerdo con lo reglado en la presente resolución y su anexo.
ARTÍCULO 8o. ACCESO A LA INFORMACIÓN REPORTADA POR LOS OPERADORES POSTALES DE PAGO POR PARTE DE AUTORIDADES PÚBLICAS. Las autoridades que, en el marco de sus competencias, ejecuten acciones vinculadas con la seguridad y defensa nacional, así como la prevención, detección, monitoreo y control del lavado de activos y financiación del terrorismo, entre otras, la Fiscalía General de la Nación, la Policía Nacional y la Unidad de Información y Análisis Financiero (UIAF), o las que hagan sus veces, podrán solicitar el acceso a la información de que trata la presente resolución, teniendo en cuenta lo establecido en la Ley 1762 de 2015 sobre instrumentos para prevenir, controlar y sancionar el contrabando, el lavado de activos y la evasión fiscal.
ARTÍCULO 9o. VIGENCIA. La presente resolución rige a partir de la fecha de su publicación en el Diario Oficial, y deroga la Resolución número 1758 de 2020, con sus respectivos anexos.
Publíquese y cúmplase.
Dada en Bogotá, D. C., a 4 de octubre de 2024.
El Ministro de Tecnologías de la Información y las Comunicaciones,
Mauricio Lizcano Arango
MINISTERIO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES
DIRECCIÓN DE VIGILANCIA, INSPECCIÓN Y CONTROL SUBDIRECCIÓN DE VIGILANCIA E INSPECCIÓN
OFICINA DE TECNOLOGÍAS DE LA INFORMACIÓN
MANUAL OPERADOR POSTAL DE PAGO
Bogotá D.C., agosto de 2024
Tabla de Contenido
Pre requisitos
1. Credenciales
2. Autenticación
3. Token JWT en los headers
Definiciones
1. Rol
Operador
Códigos de respuesta
2. Diccionario de datos (Enums)
Estado
Canal de imposición
Tipo de giro
Tipo de ámbito
Tipo de prestador de servicio
Clasificación del riesgo
Calificación del Riesgo
3. Definición Variables
3.1 Operación de reporte de transacciones de Giros Postales de Pago
3.2 Operación de reporte de Riesgo del servicio Giros Postales de Pago.
4. Endpoints
Autenticación
5. Emitir transacción
6. Reportar riesgo
6. Restablecer contraseña sesión actual
MINTIC - API Postal Pagos
El Servicio Postal Pagos es un API REST desarrollado por el MINTIC que permite la autenticación del operador de servicios postales de pago, restablecercontraseña del código de usuario habilitado, registrar los datos referentes a la operación del servicio de giros nacionales e internacionales que se realizan a través de la red postal y reportar los riesgos operativos.
A continuación, se encuentra la documentación del API, para su integración con otrosoftware o uso.
Endpoint acceso ambiente pruebas
https://cert-gyp.mintic.gov.co/Account/Login?ReturnUrl=%2F
Pre requisitos
1. Credenciales
Para hacer uso del API debe contar con credenciales del sistema válidas
{{ USUARIO }} y {{ CONTRASENA }}
2. Autenticación
Se debe realizar la solicitud al endpoint de Autenticación con las credenciales para obtener un Token JWT válido ocuando se haya vencido algún Token
3. Token JWTen los headers
A excepción de la Autenticación todas las peticiones que se realicen al API deben contener el header de Authorization con el Token JWT de la siguiente manera:
Authorization: Bearer {{ TOKEN_JWT }}
Definiciones
1. Rol
Operador
Es el rol asignado a los operadores, tienen acceso a los siguientes endpoints:
1. Autenticación (https://cert-gyp.mintic.gov.co/api/authorization/Authenticate)
2. Emitir transacción (https://cert-gyp.mintic.gov.co/api/Central/EmitirTransaccion)
3. Reportar riesgo (https://cert-gyp.mintic.gov.co/api/Central/ReportarRiesgo)
4. Restablecer contraseña sesión actual (https://certgyp.mintic.gov.co/api/Password/Restablecer)
Códigos de respuesta
En los headers de respuesta Status Http, el API entrega el código de respuesta y en la mayoría de los casos en el json derespuesta en el campo "CodigoEstado", a continuación, los códigos de respuesta más comunes son:
200: La solicitud fue exitosa
500: Ocurrieron errores internos o externos al realizar la solicitud
400: Ocurrieron errores de validación, generalmente porque no se envió un dato requerido o se enviaron valores inválidos
404: No se encontró algún elemento, por ejemplo, una ciudad con el código suministrado o no se encontró una transaccióncon el consecutivo suministrado.
401: No se tiene autorización para realizar la solicitud
403: El servidor rechazo la solicitud, generalmente ocurre cuando no se entrega un Token JWT válido
A continuación, se describen los diferentes códigos de respuesta más comunes:
| Código | Descripción | Módulo |
| 200 | Se emitió la transacción correctamente | Emitir transacción |
| 200 | Se guardaron cambios en la transacción correctamente | Emitir transacción |
| Código | Descripción | Módulo |
| 200 | Se reportó el riesgo correctamente | Reportar riesgo |
| 200 | La contraseña fue restablecida correctamente | Restablecer contraseña |
| 400 | No se logró procesar la solicitud con la información provista | Genérico |
| 400 | El tipo de operación es requerido | Emitir transacción |
| 400 | El consecutivo es requerido | Emitir transacción |
| 400 | La fecha de admisión es requerida | Emitir transacción |
| 400 | La fecha de admisión no puede ser mayor a la actual | Emitir transacción |
| 400 | El código de la ciudad de origen o código de país es requerido | Emitir transacción |
| 400 | El código de oficina de admisión es requerido | Emitir transacción |
| 400 | El tipo de prestador del servicio es requerido | Emitir transacción |
| 400 | El canal de transacción es requerido | Emitir transacción |
| 400 | El canal de transacción 'Otro' no está soportado | Emitir transacción |
| 400 | El monto es requerido | Emitir transacción |
| 400 | El flete es requerido | Emitir transacción |
| 400 | El estado es requeridO | Emitir transacción |
| 400 | El tipo de giro es requerido | Emitir transacción |
| 400 | El ámbito es requerido | Emitir transacción |
| 400 | El nit de la entidad interconexión es obligatorio para la operación de interconexión | Emitir transacción |
| 400 | El número de convenio es requerido para la operación convenio | Emitir transacción |
| 400 | El nit del contratante es requerido | Emitir transacción |
| 400 | No se puede crear la transacción porque ya existe | Emitir transacción |
| 400 | No se pueden guardar cambios, porque la transacción ya se encuentra en estado: {{ Estado }} | Emitir transacción |
| 400 | No se pueden guardar cambios, porque la transacción llegó a un estado final: {{ Estado }} | Emitir transacción |
| 400 | No se encontró la ciudad o país de origen con el código suministrado | Emitir transacción |
| Código | Descripción | Módulo |
| 400 | No se encontró la ciudad o país de destino con el código suministrado | Emitir transacción |
| 400 | La entidad interconexión no fue encontrada | Emitir transacción |
| 400 | La entidad interconexión está inactiva en elsistema | Emitir transacción |
| 400 | No se pudo emitir la solicitud con la información provista | Emitir transacción |
| 400 | El código de ciudad destino es requerida | Emitir transacción |
| 400 | La fecha de pago solo se puede asignar cuando es estado Pagado | Emitir transacción |
| 400 | La fecha de pago es requerida para el estado Pagado | Emitir transacción |
| 400 | La fecha de pago no puede ser mayor a la actual | Emitir transacción |
| 400 | No se pudo reportar el riesgo la solicitud con la información provista | Reportar riesgo |
| 400 | El formato de periodo debe tener el siguiente formato 20XX-XX | Reportar riesgo |
| 400 | El periodo es requerido | Reportar riesgo |
| 400 | El periodo es mayor no puede ser mayor a la fecha actual | Reportar riesgo |
| 400 | El riesgo operativo es requerido | Reportar riesgo |
| 400 | El factor de riesgo es requerido | Reportar riesgo |
| 400 | La clasificación del riesgo es requerida | Reportar riesgo |
| 400 | La calificación residual es requerida | Reportar riesgo |
| 400 | La calificación inherente es requerida | Reportar riesgo |
| 400 | El número de control es requerido | Reportar riesgo |
| 400 | El número de evaluación es requerido | Reportar riesgo |
| 400 | El número de evento es requerido | Reportar riesgo |
| 400 | El tipo de riesgo es requerido | Reportar riesgo |
| 400 | El correo suministrado no pertenece al usuario autenticado | Restablecer contraseña |
| 400 | El correo es requerido | Restablecer contraseña |
| 400 | Se necesita autenticación para realizar la solicitud | Restablecer contraseña |
| 400 | Solo los administradores están autorizados para realizar esta acción | Restablecer contraseña |
| 404 | La transacción aún no ha sido creada | Emitir transacción |
| Código | Descripción | Módulo |
| 404 | No se encontró un usuario con el correo suministrado | Restablecer contraseña |
| 500 | Ocurrió un error al emitir la transacción | Emitir transacción |
| 500 | Ocurrió un error al guardar el histórico de la transacción, intente de nuevo | Emitir transacción |
| 500 | Ocurrió un error al guardar los cambios en la transacción, intente de nuevo | Emitir transacción |
| 500 | Ocurrió un error al crear la transacción, intente de nuevo | Emitir transacción |
| 500 | Ocurrió un error al insertar el riesgo, intente de nuevo | Reportar riesgo |
| 500 | Ocurrió un error al reportar el riesgo | Reportar riesgo |
| 500 | Ocurrió un error al restablecer la contraseña | Restablecer contraseña |
2. Diccionario de datos (Enums)
Los tipos de dato enum que se envían dependen de los valores permitidos en su categoría y se van a recibir solo los valores correspondientes al número entero o a su nombre único.
Estado
- Creado = 1
- Inactivo = 2
- CambioDeBeneficiario = 3
- Devuelto = 4
- Pagado = 5
Tipo de operación
- GiroConvencionalDosPersonas = 1
- OperacionInterconexion = 2
- Convenio = 3
- Contrato = 4
Canal de imposición
- Físico = 5
- Electronico = 6
Tipo de giro
- GirosNacionales = 8
- GirosInternacionales = 9
Tipo de ámbito
- Nacional = 10
- InternacionalSalida = 11
- InternacionalEntrada = 12
Tipo de prestador de servicio
- OperadorHabilitado = 13
- Colaborador = 14
Tipo de riesgo
- A = 21
- B = 22
- C = 23
Tipo de factor de riesgo
- RecursoHumano = 24
- Proceso = 25
- Infraestructura = 26
- Tecnologico = 27
- Externo = 28
Clasificación del riesgo
- FraudeInterno = 29
- FraudeExterno = 30
- FallasTecnologicas = 31
- EjecucionAdministracionProcesos = 32
- RelacionesLaboralesSeguridadTrabajo = 33
- DanosActivosMateriales = 34
- ClientesProductosPracticasEmpresariales = 35
Calificación del Riesgo
- MuyBajo = 36
- Bajo = 37
- Medio = 38
- Alto = 39
- MuyAlto = 40
3. Definición Variables
3.1 Operación de reporte de transacciones de Giros Postales de Pago
| Nombre | Tipo de dato | Obligatorio | Descripción | Regla de Validación |
| Consecutivo | String | Si | Número interno único del giro definido por el operador postal, para identificar la traza de la operación de cada transacción. Máx. 100 caracteres | No se permite vacío |
| TipoOperacion | Entero | Si | Clasificación según el tipo de operación que se vaya a realizar respecto al servicio de giros postales clasificado así: GiroConvencionalDosPersonas = 1 OperacionInterconexion = 2 Convenio = 3 Contrato = 4 | No se permite vacío |
| Estado | String | Si | Clasificación de los estados por los que puede pasar la transacción: Creado = 1 Inactivo = 2 CambioDeBeneficiario = 3 Devuelto = 4 Pagado = 5 | No se permite vacío |
| FechaAdmision | String | Si | Fecha de recepción del giro yyyy-mm-dd hh:mm:ss ("2023-08-16T10:29:33") | No se permite vacío. No debe ser superior a la fecha de reporte, ya que de ser asi se toma como reporte extemporáneo. |
| CodigoCiudadOrigen | String | Si | Codigo DIVIPOLA de la ciudad o municipio de imposición del Giro | No se permite vacío |
| CodigoOficinaAdmision | String | Si | Número único asignado por el OPP para la Oficina de Admisión. | No se permite vacío |
| CodigoCiudadDestino | String | Si | Código DIVIPOLA de la ciudad o municipio de destino del Giro | No se permite vacío |
| CodigoOficinaDestinatario | String | Si | Número único asignado por el OPP para la Oficina de Admisión. | No se permite vacío |
| TipoPrestadorServicio | String | Si | Definición del Tipo de prestador de servicio del servicio definido así: OperadorHabilitado = 13 Colaborador = 14 | No se permite vacío |
| CanalTransaccional | String | Si | Clasificación del canal de imposición Fisico = 5 Electronico = 6 Otro = 7 | No se permite vacío. En caso de ser canal diferente a físico se omiten los ítems CodOfiAdmision, CodOfiAdmision, oficinaAdmision. |
| Nombre | Tipo de dato | Obligatorio | Descripción | Regla de Validación |
| Monto | decima l | Si | Monto del envío (aplica para la creación de giro) hasta 2 decimales separados por '.' | No se permite vacío |
| Flete | decima l | Si | Valor del flete del envío (aplica para la creación) hasta 2 decimales separados por '.'(200.21) | No se permite vacío |
| TipoGiro | String | Si | Clasificación del Giro: GirosNacionales = 8 GirosInternacionales = 9 | No se permite vacío |
| Ambito | String | Si | Clasificación del ámbito del servicio giro postal de pago definido asi: Nacional = 10 InternacionalSalida = 11 InternacionalEntrada = 12 | No se permite vacío |
| NitEntidadInterconexion | String | Si | Numero de identificación tributaria, que identifica el operador con quien hace procesos de interconexión cuando no tiene presencia para prestar el servicio. | No se permite vacio, cuando valor de variable TipoOperacion OperacionInterconexion = 2 |
| NumeroConvenioContrato | String | Si | Identificador de los posibles convenios o contratos que se realizan a través del servicio de giros postales de pago. | No se permite vacío, cuando valor de variable TipoOperacion Convenio = 3 o Contrato = 4 |
| NitContratante | String | Si | Numero de identificación tributaria, que identifica la empresa con quien se realizó el contrato o convenio. | No se permite vacío, cuando valor de variable TipoOperacion Convenio = 3 o Contrato = 4 |
| FechaPago | String | Si | Fecha del pago al receptor del giro yyyy-mm-dd hh:mm:ss ("2023-08-16T10:29:33") | No se permite vacío para estado PAG, DEV. Se permite vacío para estado CRE, CAM, INAC |
3.2 Operación de reporte de Riesgo del servicio Giros Postales de Pago.
| Nombre | Tipo de dato | Obligatorio | Descripción | Regla de Validación |
| Periodo | String | Si | Corresponde al año y semestre que se están reportando los riesgos operativos identificados, medidos, controlados y monitoreados por el operador postal de pago: Ejemplo (2023-02) | No se permite vacio |
| RiesgoOperativo | String | Si | Registrar el riesgo identificado por el operador postal de pago. | No se permite vacio |
| Nombre | Tipo de dato | Obligatorio | Descripción | Regla de Validación |
| FactorRiesgo | String | Si | Factor del riesgo DEFINIDOS: RecursoHumano = 24 Proceso = 25 Infraestructura = 26 Tecnologico = 27 Externo = 28 | No se permite vacio |
| ClasificacionRiesgo | String | Si | Clasificación del riesgo FraudeInterno = 29 FraudeExterno = 30 FallasTecnologicas = 31 EjecucionAdministracionProcesos = 32 RelacionesLaboralesSeguridadTrabajo = 33 DanosActivosMateriales = 34 ClientesProductosPracticasEmpresariales = 35 | No se permite vacio |
| CalificacionResidual | Int | Si | Calificación del riesgo identificado antes de la aplicación de medidas de control | No se permite vacio |
| CalificacionInherente | Int | Si | Calificación del riesgo posterior a la aplicación de medidas de control. | No se permite vacio |
| NumeroControl | Int | Si | Registrar el número de controles asignados al riesgo. | No se permite vacio |
| NumeroEvaluacion | Int | Si | Registrar asignado el número de evaluaciones realizadas a los controles s al riesgo. | No se permite vacio |
| NumeroEvento | Int | Si | Registrar reportada la cantidad de eventos de riesgo registrados en el período o asociados a cada riesgo. | No se permite vacio |
| TipoRiesgo | Int | Si | Código Descripción Generan pérdidas y afectan el estado de resultados de la entidad. A = 21 Generan pérdidas y no afectan el estado de resultados de la entidad. B = 22 No generan pérdidas y no afectan el estado de resultados dela entidad. C = 23 | No se permite vacio |
4. Endpoints
Autenticación
Este endpoint permite generar un Token JWT que servirá para Autenticarse al realizar alguna solicitudHeaders requeridos:
Ejemplo de request:
Ejemplo de respuesta exitosa:
Ejemplo de respuesta fallida:
5. Emitir transacción
Este endpoint permite registrar la emisión de una transacción guardando el histórico por cada estado por el que puede pasar.
Flujo de estados posibles
Headers requeridos:
Ejemplo de request:
Ejemplo de respuesta exitosa:
Ejemplo de respuesta fallida:
6. Reportar riesgo
Este endpoint permite reportar riesgos
Headers requeridos:
Ejemplo de request:
Ejemplo de respuesta exitosa:
Ejemplo de respuesta fallida:
6. Restablecer contraseña sesión actual
Este endpoint permite restablecer la contraseña del usuario que se encuentra autenticado.
Headers requeridos:
Ejemplo de request:
Ejemplo de respuesta exitosa:
En este caso la contraseña generada es m2C-f1cV
Ejemplo de respuesta fallida:
