Obrigações de um RCASP de Singapura
Ler a edição em PDF (3 páginas)
Um RCASP (Reporting Crypto-Asset Service Provider, prestador de serviços de criptoativos sujeito a reporte) de Singapura deve determinar se está no âmbito de aplicação, o que, para um prestador de serviços de DPT licenciado ou um licenciado DTSP, é quase sempre o caso. Deve então realizar a diligência devida sobre cada usuário: uma autocertificação de residência fiscal para pessoas físicas e entidades, a identificação das pessoas controladoras de entidades passivas e uma verificação de plausibilidade com base nas informações de prevenção à lavagem de dinheiro já disponíveis. Os usuários preexistentes devem ser documentados dentro de um período de transição, tipicamente de doze meses a partir do início. O RCASP deve reportar anualmente à IRAS (Inland Revenue Authority of Singapore, a autoridade tributária), provavelmente até 31 de maio do ano seguinte ao ano de reporte, para coincidir com o ciclo do CRS, no esquema XML da OCDE.1 O descumprimento constitui infração nos termos das disposições de compliance fiscal internacional do Income Tax Act, com multas para a entidade e para os dirigentes que deixem de agir com a diligência razoável.2
A sobreposição com a diligência devida de prevenção à lavagem de dinheiro é o ganho de eficiência que um RCASP bem organizado aproveita. A diligência devida de clientes da MAS Notice PSN02 já coleta nome, endereço, data de nascimento, nacionalidade e documentos de identificação e já identifica os beneficiários efetivos de clientes pessoas jurídicas (ver Parte L, Capítulo II). O CARF acrescenta a residência fiscal e os números de identificação fiscal e exige que a autocertificação seja feita em uma forma que o usuário assine ou confirme. Um formulário de onboarding combinado, que colete os dois conjuntos de dados de uma só vez, é a abordagem padrão. As evidências sobre o local de pertença para fins de GST descritas no Capítulo III desta Parte podem ser extraídas da mesma fonte. Um grupo suíço-singapurense com um RCASP em cada polo deve operar um único modelo de dados do CARF e dois fluxos de reporte, porque os esquemas suíço e singapurense são o esquema da OCDE e diferem apenas no canal de transmissão.
Nota prática
Quem opera uma exchange em Singapura e uma exchange-irmã em Zug deve montar o onboarding do CARF uma única vez e reutilizá-lo. Convém coletar a autocertificação na abertura da conta, validar o formato do número de identificação fiscal segundo as regras de TIN da OCDE, armazenar a jurisdição de residência como campo estruturado e vincular cada registro de operação à residência do usuário na data da operação. A agregação anual deve ser montada como um relatório que ambas as entidades possam executar. É recomendável designar um responsável pelo CARF em cada entidade, já que ambos os regimes atribuem responsabilidade a pessoas nomeadas. O output em XML deve ser testado com a ferramenta de validação da OCDE antes da primeira entrega. Um grupo que faça isso em 2025 e 2026 evita a correria que o CRS provocou em 2017 e 2018.
Notas
- OCDE, Crypto-Asset Reporting Framework, Section III (diligência devida para usuários preexistentes e novos, pessoas físicas e entidades; validade das autocertificações) e o CARF XML Schema and User Guide, 2024. ↩
- Income Tax Act 1947, Part 20B (acordos internacionais para melhorar o compliance fiscal), em especial as disposições sobre infrações e penalidades aplicáveis às instituições financeiras reportantes e, nos termos dos regulamentos do CARF, aos prestadores de serviços de criptoativos sujeitos a reporte. ↩
Apenas para informação geral. Este artigo não constitui assessoria jurídica ou tributária, não substitui a análise do caso concreto e não estabelece relação entre advogado e cliente. Reflete a situação jurídica em outubro 2026.