servicio de administración tributaria av. hidalgo, núm. 77, col

Servicio de Administración Tributaria │ Av. Hidalgo, núm. 77, col. Guerrero, delegación Cuauhtémoc, México, D. F.,

c. p. 06300 │ Tel. INFOSAT: 01 800 46 36 728 │ documento disponible en www.sat.gob.mx

1

http://www.sat.gob.mx/informacion_fiscal/normatividad/Paginas/tratados_fiscales.aspx

http://www.sat.gob.mx/informacion_fiscal/normatividad/Paginas/tratados_fiscales.aspx



2



3



4



5



6



7

La Normativa FATCA especifica que las siguientes opciones para la clasificación de las personas

morales:

1. FATCA101 = Owner-Documented FI with specified US owner(s)

2. FATCA102 = Passive Non-Financial Entity with substantial US owner(s)

3. FATCA103 = Non-Participating FFI

4. FATCA104 = Specified US Person

5. FATCA105 = Direct Reporting NFFE

Para efectos del reporte indicaríamos como FATCA102 a las entidades pasivas cuyos accionistas

mayoritarios tienen responsabilidades fiscales en EE.UU. La guía del XML señala que se requiere

información de los titulares reales aunque es posible que en ciertos casos no dispongamos de ella.



8

Analizando en detalle el documento, encontramos esta especificación:

Es decir, se indica el valor del nº de repeticiones mínimo y máximo del elemento (en nuestro caso,

“Substancial Owner” 0..”infinito”).

Según las instrucciones del propio XML, si no se indica nada se asume 1..1 para elementos

requeridos y 0..1 para opcionales y dependientes. Considerando que para otros elementos no se

ha indicado nada y que para este se ha indicado 0… “infinito”, creemos que sería posible que,

aunque fuera un campo requerido al estar reportando un AcctHolderType = FATCA102, pudieran

informarse 0 instancias de SubstantialOwner.

R.-

Revisando el documento Protocolo Seguridad FATCA v230215.docx nos gustaría aclarar

algunas dudas que tenemos. Nos apoyas por favor a transmitir lo siguiente a ABM:

El paso 8 del documento describe lo siguiente:



9

Sin embargo el WS-Policy en el archivo PolicyFatca.xml contiene lo siguiente:

Basic256Sha256Rsa15 significa que la encripción del contenido de la firma y del cuerpo

del mensaje se realizaría utilizando una llave simétrica AES-256 y esta llave simétrica se

encriptaría utilizando la llave pública RSA proporcionada por el SAT.

Me pueden confirmar por favor si el procedimiento de encripción es el que menciona el

archivo PolicyFatca.xml o hay algún detalle más que se debería considerar ya que la WS-

Policy y el Protocolo Seguridad no concuerdan completamente.

R.-



10

Enviar por favor un Excel de ejemplo. Se enviará ejemplo Se enviará ejemplo de archivo XML

-Enviar wsdl, datos de conexión (Sftp [QA y PROD] y socket [QA y PROD])

De acuerdo a la documentación enviada al SAT (escritos con personas autorizadas se

entrega información autorizada.

Nos enviarán dos certificados que son genéricos de prueba en 1ª instancia (mientras

los escritos están en trámite).

Existe una agenda de Pruebas que va programando el SAT .

Shared folder a donde se depositaran los documentos (vía sftp). à Se proporcionará cuando los

trámites del escrito estén concluidas.

Nomenclatura de archivos para el envío de sftp. Nos enviarán página de SAT.

Estas son algunas de mis dudas las cuales me gustaría aclarar.

1. Existe ya algún metodo que se haya implementado antes sobre como comprimir un archivo desde

java con gzip?

2. El servicio wsdl siatbus tiene salida a internet?

3. Quien proporcionará las llaves para la encripción SAT o HSBC?

4. Donde se depositarán las llaves para que la aplicación JAVA pueda consumirlas?



11

5. Cuando se aplique la encripción de la informació se refiere unicamente a la respuesta del wsdl o a

todo el archivo?

Sigo investigando la implementación del proyecto por mi parte debido a que los temas complicados

son los siguiente:

1. hacer el gzip sin crear el archivo físico.

2. consumir el wsdl

3. utilizar las llaves para la encriptación.

El en proceso para encriptar el archivo XML, se tiene planeado que el SAT proporcione la key

privada y la llave publica, sin embargo el equipo de ISR HSBC nos indica que seria mas viable que

HSBC genere su firma privada y publica en base a los estandares que el SAT defina, esto con la

finalidad de garantizar el resguardo y mal uso de la llave privada, la llave publica si seria

compartida al SAT.

En caso de que se decida hacer uso de las Key´s que el SAT proporciona, entonces HSBC no

tendría ninguna responsabilidad por información que sea enviada al SAT y HSBC no reconozca.

1. ¿El uso de la herramienta Soky se deberá implementar para todas las instituciones financieras independientemente del procedimiento a utilizar? Comentario SAT: la herramienta soky la podrán habilitar las instituciones

financieras que cuentan con el servicio de CECOBAN para la comunicación

con el SAT. Para las instituciones que no cuenten con dicho servicio podrán

habilitar el web service o el SFTP para envío de archivos y recepción de

acuses.

2. En el documento “Procedimiento SOCKET” se menciona que se nos proporcionara certificados, wsdl y habilitación de comunicación para establecer la encriptación y envió de información. ¿Este procedimiento es independiente a los procedimientos de SFTP y WebService? Comentario SAT: los archivos de información en formato xml tendrán que ser

comprimidos, firmados y cifrados con un certificado que le proporcionará el

SAT, independientemente del medio de comunicación por el cual se vayan a

transmitir dichos archivos. Para las pruebas el SAT generó un certificado de



12

encripción de pruebas genérico, mismo que adjunto al presente correo, y

para producción, cada institución financiera deberá solicitar el certificado

por escrito al Lic. Alfredo Federico Revilak, a través del formato adjunto a los

procedimientos de comunicación.

3. ¿Los procedimientos WebService y SFTP son excluyentes? Es decir, quedara a decisión de la institución financiera la elección de alguno de ellos. Comentario SAT: se establecieron tres medios de envío de información y

cada institución financiera elegirá el medio de comunicación por el cual

transmitirá la información al SAT y puede elegir un medio de comunicación

principal y alguno otro alterno.

4. ¿El alcance de pruebas contempla sólo la comunicación entre instituciones o también la validación en la estructura del XML? Comentario SAT: se debe establecer el medio de comunicación de prueba y

realizar envíos de información cifrados para la validación automática. En

caso de tener algún archivo de pruebas en xml, se podrá revisar vía correo

electrónico al Grupo de trabajo FATCA, [email protected];

[email protected] y su servidora [email protected].

5. ¿Se nos proporcionaran herramientas y llave para la encriptación de los archivos, tanto en ambiente de pruebas como productivas? Comentario SAT: se anexan los archivos de encripción para pruebas y de

autenticación mutua para el caso de web service de pruebas, para

producción solicitarlos conforme a los procedimientos.

mailto:[email protected]





13

Layout del contenido del archivo XML el cual debemos recoger del repositorio una vez que se haya hecho la transferencia por SFTP. Cuando es correcto contiene una cadena de caracteres con un folio ejemplo:

siatbus-response.xml

Si hay un problema de transporte el envio se rechaza, no hay folio y la cadena de

caracteres puede ser como los siguientes ejemplos:



14

siatbus-response-error-serviciofolio.xml

siatbus-response-error-userid.xml

siatbus-response-error-wss.xml

WSDL para el cliente que va a realizar la consulta de los Folios en el SAT, con el cual nos van a indicar el resultado del procesamiento del archivo XML. Esta respuesta es generada en otro momento, tenemos un tiempo de 24hrs para tener

disponible esta respuesta, Ustedes deben recuperar esta respuesta, la cual tiene como

referencia el número de folio. El contenido de estas respuestas no se encuentra

comprimido ni encriptado y podría ser como muestran los ejemplos en el archivo:

Como archivos adjuntos se encuentra el WSDL así como los XSD respectivos

1. Nuestro tool que genera el XML de FATCA muestra US en el “Issued by” se requiere de este o es opcional?

El atributo es opcional, si está presente debe tener un valor como en el ejemplo que envían, si NO

está presente se toma el valor por defecto que es US.

2. En lo que se refiere al apartado de Account balance este debe ser reportando en MXN o en USD ya que nuestro tool lo presenta en USD?

<f:AccountBalance currCode="USD">985263.25</f:AccountBalance>

Se debe enviar el balance en el tipo de moneda que maneja la cuenta, es decir si esta en euros

debe colocar EUR, supongo que la cuenta esta en dólares.



15

http://www.irs.gov/Businesses/Corporations/The-Intergovernmental-FATCA-XML-Schema-version1-1

http://www.irs.gov/Businesses/Corporations/The-Intergovernmental-FATCA-XML-Schema-version1-1

http://www.sat.gob.mx/informacion_fiscal/normatividad/Documents/fatcaxmlespanolguiausuario_18062014.pdf

http://www.sat.gob.mx/informacion_fiscal/normatividad/Documents/fatcaxmlespanolguiausuario_18062014.pdf

http://www.irs.gov/Businesses/Corporations/FATCAFAQs



16