🧾 DIAN · Circulares

Circular 2 de 2021 DIAN

(DEROGADA) - Traslado y Reporte de Recaudo de Impuestos Nacionales

Nº 22021

Ver en la fuente oficial ↗

Texto del documento

CIRCULAR EXTERNA 2 DE 2021

(marzo 30)

Diario Oficial No. 51.633 de 31 de marzo de 2021

DIRECCIÓN DE IMPUESTOS Y ADUANAS NACIONALES

PARA:	Representantes Legales y Revisores Fiscales Entidades Recaudadoras.
DE:	Director General UAE - Dirección de Impuestos y Aduanas Nacionales (DIAN) Director General de Crédito Público y Tesoro Nacional
ASUNTO:	Traslado y Reporte de Recaudo de Impuestos Nacionales

Teniendo en cuenta que con posterioridad a la expedición de la Circular 0003 de marzo 22 de 2019, se han establecido nuevos tributos con ocasión de la promulgación de la Ley 1955 de 2019 Plan Nacional de Desarrollo 2018-2022 y la Ley 2010 de 2019, es preciso armonizar las cuentas con los nuevos conceptos y adicionalmente se requiere crear y unificar códigos estadísticos para las nuevas transacciones e impartir instrucciones sobre el diligenciamiento del informe diario de recaudo, medio de transmisión y plazo de reporte, así:

1. CUENTAS VIGENTES

A continuación, se relacionan las cuentas vigentes para la transferencia de los recaudos vía SEBRA del Banco de la República, así como los códigos de operación para la exención del gravamen a los Movimientos Financieros:

El recaudo efectuado con declaraciones deberá ser trasladado a la cuenta del impuesto correspondiente.

2. INFORME DE RECAUDO DIARIO

El recaudo diario lo conforman los valores recaudados por las entidades autorizadas por concepto de tributos administrados por la U.A.E. Dirección de Impuestos y Aduanas Nacionales-DIAN en adelante DIAN, indistintamente sea su forma de recaudo: canal presencial o electrónico, bien sea en efectivo o mediante títulos.

De conformidad con lo establecido en el artículo 22 de la Resolución 478 de 2000, modificado por el artículo segundo de la Resolución DIAN 000017 del 17 de febrero de 2021: “Para todos los efectos, la fecha del recaudo por cualquier canal dentro de los horarios especiales, adicionales y extendidos manejados por las entidades autorizadas para recaudar será la que corresponde a la fecha en que se realice el pago; en consecuencia, los informes y el traslado de los recursos atenderán esta fecha. (…).

En este orden de ideas, los sábados, domingos y festivos, serán tomados como un día de recaudo normal, iniciando el término de compensación el día calendario siguiente.

En cuanto al traslado del recaudo a las cuentas del Banco de la República, se mantiene lo dispuesto en el inciso 4 del artículo 38 de la Resolución 478 de 2000, modificado por el artículo 1o de la Resolución 3083 de 2007, según el cual, si la fecha del traslado o consignación del recaudo al Banco de la República coincide con sábado, domingo o festivo, este se realizará el día hábil siguiente.

El formato FT-RE-2495 “Informe diario de recaudo” versión 2, anexo 1, que se utiliza para transmitir la información diaria de recaudo a través de correo electrónico, deberá implementarse a partir del recaudo correspondiente al día 12 de abril de 2021. Es de anotar que este formato no debe ser objeto de modificación o alteración alguna. De esta forma, la sección detallada dentro de la planilla para los recaudos en horario extendido, a partir de esa fecha debe venir en cero o en blanco. De lo contrario, este informe no podrá ser cargado dentro de los aplicativos usados para este fin.

A partir del 8 de junio de 2021 las entidades autorizadas para recaudar deberán transmitir a la DIAN y a la Dirección General de Crédito Público y Tesoro Nacional el informe diario de recaudo a través del canal web service dispuesto para tal fin, conforme a las especificaciones contenidas en los anexos 2 y 3 de la presente Circular.

Una vez se implementen los webs services de la DIAN y de la Dirección General de Crédito Público y Tesoro Nacional, en caso de no disponibilidad del canal para la transmisión del informe diario por contingencia debidamente comunicada por la DIAN o la Dirección General de Crédito Público y del Tesoro Nacional, será procedente el envío del informe vía correo electrónico a los siguientes buzones: DIAN: controlrecaudo@ dian.gov.co y Dirección General de Crédito Publico y Tesoro Nacional: tesoreria@ minhacienda.gov.co. Una vez restablecidos los canales de transmisión (web service), las entidades autorizadas para recaudar deberán enviar por este medio los informes pendientes de transmitir, a más tardar el día hábil siguiente a la fecha de restablecido el servicio.

Es requisito que cada uno de los archivos sea nombrado en el siguiente orden:

IRD-BB_01_DDMMAAAA.xlsx

IRD-BB_02_DDMMAAAA.xlsx

IRD: Corresponde al nombre del archivo Informe de Recaudo Diario

BB: Corresponde al código del Banco

01: Informe Inicial

02: Informe Modificado

DDMMAAAA: Es la fecha de recaudo que se informa día-mes-año

El informe de recaudo diario se presentará el día hábil siguiente a la fecha de recaudo informada, a más tardar a las once horas (11:00).

3. CÓDIGOS ESTADÍSTICOS:

Los siguientes son los códigos estadísticos:

4. ANEXOS

Forman parte de la presente Circular los siguientes anexos:

Anexo 1: FT-RE-2495 “Informe diario de recaudo” versión 2

CONSULTAR ANEXO EN EL ORIGINAL IMPRESO O EN FORMATO PDF.

5. VIGENCIA Y DEROGATORIAS

La presente Circular rige a partir del 12 de abril de 2021, previa su publicación en el diario oficial y deroga en todo su contenido la Circular Externa 000003 de marzo 22 de 2019.

Publíquese y cúmplase.

Dada en Bogotá, D. C. a 30 de marzo de 2021.

El Director General, UAE Dirección de Impuestos y Aduanas Nacionales (DIAN),

Lisandro Manuel Junco Riveira.

Servicio Web Estándar de Informe de Recaudo Diario.

Contrato de Servicio.

Tabla de contenido

1. Control de versiones.

2. Notas de la liberación de versiones.

3. Especificación del Servicio.

3.1. Información General Servicio

3.2. Funcionalidad.

4. Operaciones del Servicio.

4.1. Seguridad del llamado de los servicios.

4.2. Operación: Informar Recaudo Diario.

4.2.1. Información General Operación

4.2.2. Entradas.

4.2.3. Salidas.

5. Riesgos.

6. Anexos.

6.1. Tablas de códigos.

Severidad de la Respuesta.

Código del Banco.

Indicador del informe.

Horario.

Tipo de Recaudo.

Estado del pago.

Código estadístico.

6.2. Especificaciones técnicas REST

1. Control de versiones

Versión	Fecha (dd/mm/aaaa)	Responsable	Descripción
1.0	19/03/2019	Clímaco Llamas Ernesto Medina	Especificación Inicial del Servicio
1.1	14/02/2020	Clímaco Llamas	Corrección de url del servicio
1.2	30/03/2020	Clímaco Llamas	Ajuste de tablas de códigos estadísticos acorde a la circular externa 3 de 22 de marzo de 2019
1.3	30/04/2020	Clímaco Llamas	Ajuste a tabla de códigos estadísticos y tabla de tipos de recaudo.
1.3.1	12/05/2020	Climaco Llamas	Ajuste a valor de atributo esReemplazo en los ejemplos.
1.4	30/10/2020	Climaco Llamas	Se adicionan tipos de recaudo y se eliminan códigos COVID

2. Notas de la liberación de versiones

Versión 1.0

- Especificación Inicial del Servicio

Versión 1.1

- Corrección de url del servicio. Cambios en amarillo. Ítem 3.1 y 4.2.1

Versión 1.2

- Ajuste a tabla de códigos estadísticos

Versión 1.3

- Se adicionan los códigos estadísticos 014 y 015. Se cambia el nombre al tipo de recaudo 1, pasa de Efectivo a Efectivo Presencial y se adiciona el tipo de recaudo 3 denominado Efectivo Canales Electrónicos.

3. Especificación del Servicio

3.1. Información General Servicio

Nombre Servicio	Servicio de Informes de Recaudo
Nombre Técnico	Informes de Recaudo
Espacio de Nombres Producción	http://api.dian.gov.co/recaudo/informes
Espacio de Nombre Pruebas	http://apipruebasexternas.dian.gov.co/recaudo/informes
Versión	1.0

3.2. Funcionalidad

La Entidad Financiera (Banco) consume el Web Service de la DIAN.

1. La aplicación de la entidad financiera construye según la especificación definida el mensaje para informar el recaudo diario.

2. La aplicación de la Entidad Financiera consume la operación de informar el recaudo del Servicio Web de la DIAN

3. El servicio de la DIAN valida la consistencia de los datos

4. El servicio de la DIAN envía respuesta.

4. Operaciones del Servicio

4.1. Seguridad del llamado de los servicios

Se debe aclarar que todas las operaciones expuestas para Recaudo en Caja, deben llevar en el encabezado la información del ClientId y el Authorization.

Nombre del Campo (Path)	Descripción	Obligatoriedad	Longitud	Tipo
Header del request para cualquier método
clientId	Entregado por la DIAN, identificador dado a la aplicación registrada.	S	50	Alfanumérico
Authorization	Es el idToken obtenido en la autenticación con identidad.	S	500	Numérico

Ejemplo del header:

…

Authorization: Bearer

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI5MDAwMDAwMDA2MDAwNC0wLTg5MDkwMzkzOCIsImF1ZCI6WyJLVHNsTEg3UmhOeWxHOGZHQjlXM0FScjhmbEFhIl0sImlzcyI6Imh0dBzOlwvXC9tdWlzY2EuZGlhbi5nb3YuY28iLCJleHAiOjE1MjIyNjEyNTIsImlhdCI6MTUyMjI1NzY1Miwicm9sIjoiaHR0cHM6XC9cL2dvb2dsZS5jb20uY28iLCJqdGkiOiIzZDMzOWFjZC1lMzM1LTRiMGUtYjFlYy01NTgzYzQxY2M5NTcifQ.IX1O_b5kpK_gX4He8JzX-NiYuhOB4sUdGvvH5r8rl2wclientId: KTslLH7RhNylG8fGB9W3ARr8flAa

…

4.2. Operación: Informar Recaudo Diario

4.2.1. Información General Operación

Nombre Operación	Entrega de Informe de recaudo diario
Nombre Técnico	informesdiarios
Comando HTTP Ambiente Producción	POST https://api.dian.gov.co/recaudo/informes/v1/informesdiarios/{fecha}
Comando HTTP Ambiente Pruebas	POST https://apipruebasexternas.dian.gov.co/recaudo/informes/v1/ informesdiarios/{fecha}
Descripción Operación	La entidad financiera notifica a la DIAN el recaudo del día
Precondiciones	- El sistema de la DIAN debe estar funcionando - La aplicación de la entidad financiera tiene un token valido
Post condiciones	- El sistema de la DIAN recibe la notificación del informe diario de recaudo y retorna un acuse de recibo acorde a la información enviada

4.2.2. Entradas

El mensaje de request en formato JSON se va a llamar DInformeDiario. Está formado por los objetos DEncabezadoInforme y DInforme y cada uno de ellos se compone de los campos definidos a continuación:

Nombre del Campo (Path)	Descripción	Obligatoriedad	Longitud	Tipo
DEncabezadoInforme
idTransaccion	Identificador único de la transacción. El id transacción es un número único, no se debe repetir. Por cada operación que ustedes consuman de informarRecaudoDiario deben generar un id de transacción. Se realiza la petición con ese número único de transacción y el servicio le responde entregándole ese id de transacción. Esto se definió como un mecanismo de control para garantizar que la respuesta corresponde a la petición que se realizó.	S	36	Alfanumérico
codigoBanco	Corresponde al código de compensación de la entidad financiera que realiza la operación. Ver tabla de valores	S	4	Numérico
fechaTransmision	Fecha de transmisión del mensaje. Aplicar la notación yyyy-mm-ddThh:mm:ss de la ISO 8601	S	N/A	Fecha
idioma	Lenguaje preferido definido por la IETF RFC 1766. Valor por defecto es-co	S	5	Alfanumérico
DInforme
fechaRecaudo	Fecha del reporte del recaudo. Aplicar la notación yyyy-mm-dd de la ISO 8601	S	N/A	Fecha
esReemplazo	Indica si es el primer reporte o es un reemplazo de un reporte previo enviado. Ver tabla de valores	S	1	Numérico
valorRecaudo	Valor total del recaudo reportado por concepto y tipo de recaudo	S	18	Numérico
conteoDetalles	Conteo del numero de elementos que vienen en los detalles	S	3	Numérico
hash	Es un hash generado por la entidad financiera con información que solo ella conoce e información de la transacción. Ver detalles de su generación en el apartado 4.2.3.6 Calculo del hash	S	1000	Alfanumérico
detalles	Es una lista de objetos DInformeDetalle que informa el recaudo por concepto y por tipo de recaudo	S	N/A	DInformeDet alle
Nombre del Campo (Path)	Descripción	Obligatoriedad	Longitud	Tipo
DInformeDetalle
concepto	Especifica el medio de pago. Los ceros a la izquierda deben informarse. Ver tabla de valores.	S	3	Alfanumérico
tipoRecaudo	Especifica las formas de pago con el cual realizó el recaudo. Ver tabla de valores.	S	2	Numérico
valorNormal	Valor recaudado en el horario normal	S	18	Numérico
valorExtendido	Valor recaudado en el horario extendido y/o adicional	S	18	Numérico
DInformeDiario
encabezado	Objeto de tipo DEncabezadoInforme	S	N/A	DEncabezad oInforme
informe	Objeto de tipo DInforme	S	N/A	DInforme

4.2.2.1. Ejemplo del mensaje request para consulta

4.2.2.2. Ejemplo de trama de request para Consulta

POST /GerPagoBancosRest_Recaudo/api/v1/informesdiarios/2019-03-13 HTTP/1.1

Host: 10.255.5.103:8282

Connection: keep-alive

Content-Length: 673

Authorization: Bearer

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI5MDAwMDAwMDA2MDAwNC0wLTg5MDkwMzkzOCIsImF1ZCI6WyJLVHNsTEg3UmhOeWxHOGZHQjlXM0FScjhmbEFhIl0sImlzcyI6Imh0dHBzOlwvXC9tdWlzY2EuZGlhbi5nb3YuY28iLCJleHAiOjE1MjIyNjEyNTIsImlhdCI6MTUyMjI1NzY1Miwicm9sIjoiaHR0cHM6XC9cL2dvb2dsZS5jb20uY28iLCJqdGkiOiIzZDMzOWFjZC1lMzM1LTRiMGUtYjFlYy01NTgzYzQxY2M5NTcifQ.IX1O_b5kpK_gX4He8JzX-NiYuhOB4sUdGvvH5r8rl2w ClientId: KTslLH7RhNylG8fGB9W3ARr8flAa

{

4.2.3. Salidas

El mensaje de response en formato JSON se va a llamar DRespInformeDiario. Está formado por los objetos DEncabezadoRespuesta y DConfirmacionInformeDiario y cada uno de ellos se compone de los campos definidos a continuación:

Nombre del Campo (Path)	Descripción	Obligatoriedad	Longitud	Tipo
DEncabezadoRespuesta
idTransaccionOrigen	Identificador único de la transacción. Debe coincidir con el idTransaccion de la petición.	S	36	Alfanumérico
codigoRespuesta	Código de respuesta retornado por el Web Service de la DIAN. Ver tabla de valores	S	3	Numérico
severidad	Severidad de la respuesta. Ver tabla de valores	S	10	Alfanumérico
descripcionEstado	Descripción del estado de la respuesta, generado por el sistema.	S	255	Alfanumérico
fechaRespuesta	Fecha y hora de la respuesta. Aplicar la notación yyyy-mm-ddThh:mm:ss de la ISO 8601	S	N/A	Fecha
idioma	Lenguaje en la que está la respuesta, definida por la IETF RFC 1766. Valor por defecto es-co	S	5	Alfanumérico
DConfirmacionInformeDiario
versionServicio	Versión de Servicio	S	36	Alfanumérico
comprobante	Número de Comprobante	S	36	Alfanumérico
estado	Estado de la operación. Ver tabla de valores	S	36	Alfanumérico
hash	Cadena de confirmación que envía la DIAN y se genera usando el PrivateKeyDian, para que el banco lo verifique con la PublicKeyDian.	S	1000	alfanumérico
DRespInformeDiario
encabezado	Objeto de tipo DEncabezadoRespuesta	S	N/A	DEncabezad oRespuesta
confirmacion	Objeto de tipo DConfirmacionInformeDiario	S	N/A	DDocumento

4.2.3.1. Ejemplo del mensaje response para consulta con respuesta exitosa

4.2.3.2. Ejemplo de trama response para request con respuesta exitosa

4.2.3.3. Ejemplos del mensaje response para request con respuesta no exitosa

4.2.3.4. Ejemplo de trama response para consulta con respuesta no exitosa

HTTP/1.1 400 Bad Request

4.2.3.5. Mensaje response para códigos de respuesta 401, 500 y 503

Los códigos de respuesta 500, 503 o 401 no se responden usando la estructura definida en los servicios debido a que nunca alcanza a llegar al servicio. Son interceptados por la capa de seguridad o arquitectura y devueltos con el código HTTP y una breve descripción.

Los mensajes entregados tienen la siguiente estructura

{

"codigo": 401,

"mensaje": "Autenticación fallida",

"descripcion": "Datos de autenticación inválidos"

}

{

"codigo": 401,

"mensaje": "Unauthorized",

"descripcion": "The request requires user authentication"

}

{

"codigo": 500,

"mensaje": "ClientId no autorizado para utilizar este token",

"descripcion": "java.lang.Exception: ClientId no autorizado para utilizar este token"

}

{

"codigo": 503,

"mensaje": "Autenticación fallida",

"descripcion": "Autenticación no disponible

}

4.2.3.6. Cálculo del hash.

El hash que se solicita en la notificación no está relacionado con el hash que se usa en la consulta (correspondiente a un numero de 6 cifras). Es un atributo que se debe calcular para cada operación basado en el algoritmo RSA-2048. A continuación, se explica la forma de generarlo:

1. Los Bancos generan par de llaves PublicKeyOrg, PrivateKeyOrg y entregan la PublicKeyOrg a la DIAN.

2. La DIAN entregará la cadena PublicKeyDIAN con la cual los bancos calcularán el hash para la notificación y esta llave debe ser resguardada por la entidad y no debe hacerse pública.

3. Se deben concatenar los atributos [idTransaccion]-[valorRecaudo]-[fechaRecaudo]- [esReemplazo]- [conteoDetalles]. Ejemplo:

a. Se tiene un PrivateKeyOrg, que para este ejemplo será "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvSTdhStV02HptklX7ijmzaMQH8I6zNsAazak6bBj01QHBU+HA3b/irV41DnzbdnpkUxG0pUC72EyCXFKz2ULXtg4TVmw5zNji3BY2x45v2rC1TT3vdgkRf9LCmZ+ks7a5bUwKbe/DHl05bah4BI29CU3G+ntWANoPCknZWxZFSEPdNukaSuqRmaKCCHRdSpxr2L4k048ju6fGtuSaZ4JMDTicM5WUrpqGrIkuOl9IkkPqAr6UEWCUzZsbAeQHOQkJXV0VnUg6HbaqLlAkIg0b6cW8e+BX+bBpwv8XSOPKyUS4tqAfcZdxP5t7PlrYFbPmFAnHX4fatDAAkHthUtrqwIDAQAB".

b. El idTransacción es "92b17643-328a-4a66-b283-c02741fe8e9c".

c. Un valor recaudado de "1345000"

d. Y una fechaRecaudo igual a "2018-08-12"

e. esReemplazo igual a 1

f. conteoDetalles igual a 5

Debo concatenar dichos valores así, sin espacios:

[92b17643-328a-4a66-b283-c02741fe8e9c]-[1345000]-[2018-08-12]-[1]-[5]

A dicha cadena se le debe aplicar el algoritmo un cifrado RSA-2048 obteniendo el resultado:

"uqIpgh8E3TD70hWcSJhjuopFI0s9okZjdbpNuCWlhPu8gSNbiQbo6/AyZanEMSwDMkAU5soS6misweCSgCrVQXZZ6yyrk0qRAmrqFFS16yo+5c+poNK2l3z0A+/2CGCtfi7Xhisso0aG/VF8SHR+WxGNrEIHXka8t+cGZrSbE4fBPhW9KpURrO8o3X6ftPBunQd4ZVWGJiwCSk+6wpB31HOU39+kCj88LHu/mIrYnSnPyw/9m1ksOy3wrTtVDZQVbg1r/erk/wLjy+GUD3hXDpy0z7BCTYymyMrOjufYEvqMJ1C+buaAEoBj57j4Rr/7RjTdW96vcUwX14qFFgIh2A=="

NOTA: Sin las comillas.

4. El valor resultado del RSA-2048, es decir la cadena

5. La DIAN usará el PublicKeyOrg para descifrar y así verificar que la información realmente fue generada por el banco (cada entidad tiene un PrivateKeyOrg único, el cual no podrá compartir y será su responsabilidad el proteger el acceso al mismo). Una vez se aplique, la cadena se obtiene:

[92b17643-328a-4a66-b283-c02741fe8e9c]-[1345000]-[2018-08-12]-[1]-[5]

Que representa la cadena originalmente emitida y que corresponde a los valores que vienen en la transacción.

6. La DIAN usará su PrivateKeyDIAN para generar un hash que hace parte del acuse de recibo.

5. Riesgos

Elección del modelo de seguridad.

Teniendo en cuenta la flexibilidad en el modelo de seguridad, la DIAN define las condiciones de seguridad de su servicio y los riesgos de seguridad.

El representante de la DIAN debe definir, en conjunto con el equipo técnico de su entidad, los controles que se implementarán en la integración entre las dos entidades. Para esta actividad puede asesorarse con el personal de la Entidad Financiera. Una vez definidos se deberán marcar en este documento, en la siguiente sección, ya que hace parte del Web Service a implementar entre la Entidad Financiera y la DIAN por lo que es de estricto cumplimiento por ambas partes.

A continuación, marque con una X los controles definidos con el equipo técnico en el desarrollo del servicio. Se debe tener en cuenta que se pueden tener varios controles para mitigar el mismo riesgo y que se repiten controles para los diferentes riesgos. (Como mínimo se debe seleccionar un control por riesgo).

Riesgo	Captura de información en tránsito
Detalle del riesgo	Una persona mal intencionada puede interceptar los datos que se intercambian entre La Entidad Financiera y la DIAN mediante técnicas de hombre en el medio o de captura de información en tránsito. La fuga de esta información puede ser usada para desprestigiar la imagen de alguna de las dos organizaciones o puede ser usada en contra de los clientes del recaudador. Ambas empresas, tanto la Entidad Financiera como la DIAN, tienen la responsabilidad de proteger esta información lo que implica que se puede llevar a un incumplimiento regulatorio o demandas por parte de los clientes. Si mecanismo de autenticación definido entre las partes para realizar las operaciones es basado en usuario y contraseña (autenticación básica), el no proteger la información en tránsito puede llevar a una suplantación posterior. La Entidad Financiera no puede, por regulación de la Superintendencia Financiera, establecer la conexión sin la elección de alguno de los siguientes controles.
Tipo de control	Cifrado de los datos en tránsito entre las dos entidades	Elección
Controles	Control: VPN Efectividad: Media Riesgo residual: No se protege la conexión de extremo a extremo, ya que la VPN se realiza usualmente entre firewall o equipos de borde de la red, quedando un tramo de la comunicación sin mecanismo de cifrado entre el equipo de borde y el servidor que expone el servicio. También están los riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación.
Control: HTTPS Efectividad: Alta Riesgo residual: En ocasiones la capa del HTTPS llega hasta un balanceador de carga o algún equipo de borde relacionado con seguridad (WAF, Proxy reverso, Security Gateway, etc) que se encuentra como intermediario, dejando la comunicación expuesta en el tramo restante. También están los riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación.
Riesgo	Suplantación de la DIAN
Detalle del riesgo	Una persona mal intencionada puede ubicar un sistema en el medio de la comunicación haciéndose pasar por la DIAN, bajo la técnica de hombre en el medio. Habiendo hecho esto puede hacer 3 cosas: 1. Recibir todas las conexiones provenientes de la Entidad Financiera y no llevarlas a la DIAN, causando una denegación de servicio. Si el sistema responde a las peticiones de la Entidad Financiera en un formato válido, la denegación de servicio se detectaría al hacer un proceso de conciliación. 2. Capturar la información que se transmite entre la Entidad Financiera y la DIAN, que puede incurrir en una futura suplantación de la Entidad Financiera. Más detalle en el riesgo "Captura de información en tránsito" de este documento. 3. Modificación de los datos transmitidos para su propio beneficio o de terceros. Más detalle en el riesgo "Perdida de integridad de los mensajes".
Tipo de control	Mecanismo para autenticar al recaudador	Elección
Controles	Control: VPN Efectividad: Alta Riesgo residual: No se protege la conexión de extremo a extremo, ya que la VPN se realiza usualmente entre firewall o equipos de borde de la red. La Entidad Financiera autenticaría al otro extremo de la VPN pero no al equipo donde se expone el servicio. También están los riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación.
Control: HTTPS Efectividad: Alta Riesgo residual: Riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación
Riesgo	Suplantación de la Entidad Financiera
Detalle del riesgo	Se podría suplantar a la Entidad Financiera inyectando tramas en el servicio de la DIAN para generar eventos de fraude donde se realicen notificaciones de un recaudo sin tener un proceso de recaudo de dinero real. El riesgo está asociado al tipo de negocio de la DIAN. Por ejemplo, el pago de facturas de mercancía puede involucrar la entrega de éstas antes de poder validar la veracidad del recaudo.
Tipo de control	Mecanismo de autenticación de la Entidad Financiera	Elección
Controles	Control:Validación de IP Efectividad: Baja Riesgo residual: La dirección IP puede ser suplantada tanto en redes internas como en redes externas a la DIAN. Nota: Se recomienda siempre usar este control como complementario por la facilidad de implementación.
Control: Autenticación básica (Usuario de conexión y contraseña) Efectividad: Media - baja Riesgo residual: El usuario y contraseña en un escenario ideal debe ser asignado y parametrizado en los sistemas de la DIAN por la Entidad Financiera. En un proceso diferente es posible que no se tenga una custodia transparente y puede incurrir en fraude interno. Si se analiza en conjunto con los riesgos "Captura de información en tránsito" y "Suplantación del recaudador" las credenciales pueden ser capturadas por una persona mal intencionada con el fin de suplantar a la Entidad Financiera.
Control: VPN Efectividad: Media Riesgo residual: Una vez establecida la VPN es posible definir qué sistemas pueden enviar información a través de la VPN. Sin embargo, hay un riesgo de suplantación por sistemas internos, ya que la validación se realiza sólo en la VPN y no en el servicio expuesto. También están los riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación.
Control: Autenticación de cliente en el HTTPS Efectividad: Alta Riesgo residual: Riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación.
Control: Validación de firma digital de mensajes enviados por la Entidad Financiera. Efectividad: Alta Riesgo residual: Riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación
Riesgo	Perdida de integridad de los mensajes
Detalle del riesgo	La ausencia de un control de integridad permite modificar los mensajes intercambiados entre la DIAN y la Entidad Financiera. Esto permite la modificación de valores para lograr un fraude en el que el valor pagado difiere al valor reportado al recaudador.
Tipo de control	Mecanismo de validación de integridad de los datos	Elección
Controles	Control: VPN Efectividad: Media Riesgo residual: El control de integridad se da entre los equipos de borde de las empresas, dejando fuera del alcance del control las conexiones que hay entre los equipos de borde y los sistemas del servicio. También están los riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación.
Control: HTTPS Efectividad: Media - alta Riesgo residual: En ocasiones la capa del HTTPS llega hasta un balanceador de carga o algún equipo de borde relacionado con seguridad (WAF, Proxy reverso, Security Gateway, etc.) que se encuentra como intermediario, dejando la comunicación expuesta en el tramo restante. También están los riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación.
Control: Firma digital Efectividad: Alta Riesgo residual: Existen riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación.
Riesgo	Posible ausencia de validez jurídica de mensajes intercambiados con la Entidad Financiera por falta de una firma digital o firma electrónica.
Detalle del riesgo	Las firmas digitales además de ser un control técnico también son consideradas un control jurídico, donde una firma de un mensaje intercambiado por las entidades y éste firmado tiene una validez jurídica si se realiza de forma adecuada. La ausencia de esta firma puede implicar la ilegitimidad del mensaje ante un juez.
Tipo de control	Mecanismo de no repudio con validez jurídica	Elección
Controles	Control: Firma digital con certificado firmado por entidad certificadora válida externa. Efectividad: Alta Riesgo residual: Existen riesgos relacionados a la criptografía, que en una evaluación de alto nivel se pueden considerar despreciables asumiendo la correcta implementación.

6. Anexos

6.1. Tablas de códigos

Código de Respuesta

Código Respuesta	Nombre Respuesta	Detalle de la Respuesta	Acción a Seguir por el Banco
200	Éxito	La transacción ha sido exitosa	N/A
400	Formato Invalido	El formato de la trama es incorrecto. Para el caso en que se presente que el mensaje llegue corrupto o con JSON mal formado al cliente.	Ajustar la trama y enviarla nuevamente
401	Acceso no Permitido	El header de autenticación no es válido. Acceso denegado a aplicación.	Obtener un token valido y enviar la trama
403	Ya fue enviado	El informe ya fue enviado para la fecha de recaudo especificada	Se requiere informar que es un reemplazo con una fecha-hora superior al enviado anteriormente.
404	No se encuentra un informe con los criterios dados.	Cuando se envía el informe de reemplazo y no se encuentra un informe inicial	Ajustar los datos del informe y enviar nuevamente
405	Plazo cerrado	La fecha de recaudo reportada en el informe supera la fecha límite para la entrega del mismo	Ajustar los datos del informe y enviar nuevamente
406	Valor Incorrecto	El valor total del recaudo reportado no es igual a la sumatoria del detalle reportado	Ajustar los datos del informe y enviar nuevamente
409	Nro. de Transacción Duplicado	El identificador de la transacción ya se encuentra relacionado a otro informe	Ajustar los datos del informe y enviar nuevamente
417	Hash de verificación errado	Se genera cuando el hash RSA-2048 es incorrecto.	Ajustar los datos del informe y enviar nuevamente
503	Mantenimiento del Sistema	Mantenimiento de la plataforma o sistema. Para el caso en que el cliente realice mantenimientos preventivos al sistema.	Realizar reintentos acordes al modelo operativo
Código Respuesta	Nombre Respuesta	Detalle de la Respuesta	Acción a Seguir por el Banco
504	Error de Conexión	Falla de infraestructura. Para cuando se presenten errores en el canal de comunicación.	Realizar reintentos acordes al modelo operativo

NOTA: El error 503 o 401 no se responden usando la estructura definida en los servicios debido a que nunca alcanza a llegar al servicio. Son interceptados por la capa de seguridad y devueltos con el código HTTP y una breve descripción.

Severidad de la Respuesta

Código Respuesta	Detalle de la Respuesta
ERROR	Hubo un error en la petición lo suficientemente severa para que no se pudiera dar una respuesta. La transacción no fue procesada.
WARNING	Hubo un problema con la petición, pero se presenta una respuesta válida. La transacción fue procesada exitosamente,
INFO	La transacción fue procesada exitosamente,

Código del Banco