Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alteraçõesINTERNAL entre dois clientes da Didit, o protocolo aberto Travel Rule (TRP) e EMAIL. Os quatro canais de rede (GTR, TRUST, VERIFYVASP, SYGNA) exigem uma adesão a essa rede do lado do remetente.
Esta página indica o que cada um faz atualmente, para saber onde pode contactar as suas contrapartes antes de depender de uma rota.
Estado em resumo
“Funciona” significa que a Didit envia o pedido e lê a resposta. “Implementado, ainda não comprovado em funcionamento” significa que a Didit envia o pedido e lê a resposta da rede, mas ainda não foi concluída nenhuma troca através dessa rede com uma rede ativa. Nenhum destes estados significa que uma determinada contraparte está acessível: isso depende da contraparte, e as
routes de cada VASP no diretório indicam quais os canais que a sua aplicação pode usar para essa contraparte neste momento.
EMAIL transporta apenas os seus pedidos de saída: a página de resposta é onde uma contraparte responde a um deles, e nenhuma VASP lhe pode enviar uma transferência por e-mail.
Antes de depender de GTR, VerifyVASP, Sygna Bridge ou TRUST, ligue a sua adesão e execute uma primeira troca com uma contraparte que conheça.
Canais que não exigem adesão
INTERNAL
Ambas as VASP funcionam na Didit, por isso a troca é liquidada dentro da plataforma, sem chamada de saída. O destinatário tem de ser um cliente ativo da Didit com a Travel Rule ativada, que tenha comprovado o controlo da carteira de destino com uma mensagem assinada ou um depósito de teste. Uma carteira autodeclarada, apenas com uma captura de ecrã ou não verificada não recebe nada. Consulte Envio de uma transferência.TRP
A Didit implementa nativamente o protocolo Travel Rule. Uma transferência segue porTRP quando inclui o Travel Address da contraparte, quando a entrada do livro de endereços da carteira de destino guarda um, ou quando a contraparte se resolve no diretório com um endpoint TRP que o diretório verificou.
Cada troca TRP que não termina numa única chamada precisa do host TRP público da Didit, aquele para onde apontam os Travel Address:
- Envio. Uma contraparte que responde ao seu pedido de imediato, na própria resposta, conclui ou recusa a transferência. Uma contraparte que responde mais tarde publica a resposta no host TRP da Didit, por isso essa troca não pode concluir enquanto o host não estiver ativo; a transferência fica a aguardar e expira na data-limite. A Didit envia o pedido uma única vez e não tenta novamente: quando o host TRP da contraparte não pode ser contactado ou recusa o pedido, a transferência passa de imediato para
COUNTERPARTY_VASP_NOT_REACHABLE, e pode tentá-la de novo comaction: "resend". - Receção. As outras VASP chegam até si através do seu Travel Address nesse host, por isso nenhuma contraparte lhe pode enviar um pedido TRP enquanto o host não estiver ativo.
Redes de transferência
Com a sua própria adesão
Ligue a sua própria adesão na Marketplace da consola (categoria Redes Travel Rule). As suas transferências seguem então com a sua própria identidade de rede, e uma adesão ligada tem sempre prioridade sobre a da Didit.
A GTR, a TRUST e a VerifyVASP aceitam também, de forma opcional, um certificado de cliente para TLS mútuo, uma chave de cliente e um pacote CA (PEM), para uma adesão que use TLS mútuo ou uma CA privada.
- A Didit envia em segundo plano e volta a tentar numa rede que não responde, ou que responde com uma falha temporária (sem resposta a tempo, uma ligação falhada, HTTP
408,429ou5xx): após 30 segundos, depois 2, 10, 30 e 60 minutos. Após a sexta tentativa falhada, a transferência passa aCOUNTERPARTY_VASP_NOT_REACHABLE. Uma recusa, como outra resposta4xxou um redirecionamento, não é repetida: a transferência passa de imediato aCOUNTERPARTY_VASP_NOT_REACHABLE. - Uma transferência cuja resposta nunca chega fica em
AWAITING_COUNTERPARTYaté passarconfirmation_timeout_hours; depois expira e aplica o seutimeout_outcome. - A receção de uma transferência que outro VASP lhe envia através da GTR, da VerifyVASP ou da Sygna Bridge ainda não está ativada: a Didit ativa-a por rede e, até lá, essas redes não podem entregar-lhe transferências.
- Guardar uma adesão devolve
400quando o código do participante é o código próprio da Didit nessa rede, ou um código que outra aplicação já tem. - Os pedidos à rede levam as suas credenciais apenas para o host dessa rede e nunca seguem um redirecionamento. O pacote de dados TRUST é enviado ao beneficiário sem a sua chave de API, ID de membro ou certificado de cliente.
Através da adesão da Didit
Quando a Didit tem uma adesão à rede, um cliente sem adesão própria pode aceder à rede como participante em nome próprio, através da adesão da Didit, com o código de participante que a rede lhe atribui: as mensagens enviadas referem o seu código, nunca o da Didit. Isto está disponível apenas para a GTR e a Sygna Bridge. A TRUST admite membros um VASP de cada vez e um Enclave VerifyVASP serve um único VASP, pelo que ambas só são acessíveis com a sua própria adesão. A adesão faz-se em três passos: responder ao questionário de diligência devida da rede da Didit, aguardar que a Didit o aprove e, depois, solicitar o acesso à rede. A Didit regista-o na rede, e o seu participante fica ativo assim que a rede lhe atribuir um código. Este fluxo ainda não está aberto. Enquanto não estiver, guardar ou submeter o questionário e solicitar acesso a uma rede devolvem403 com code: travel_rule_platform_networks_disabled, e GET /v3/travel-rule/networks/ indica platform_networks_enabled: false.
Ler o estado da sua aplicação
GET /v3/travel-rule/settings/ e GET /v3/travel-rule/networks/ devolvem networks, indexado por gtr, trust, verifyvasp e sygna. Cada entrada indica o que a rede pode fazer pela sua aplicação neste momento:
mode resume o estado como own, didit, off ou unavailable. A sua própria adesão é verificada primeiro, depois disabled_networks e, por fim, a adesão da Didit. Atualmente, uma rede fica com own_membership assim que liga a sua própria adesão. Caso contrário, a GTR e a Sygna Bridge ficam com didit_onboarding (unavailable com sandbox_application numa aplicação sandbox), e a TRUST e a VerifyVASP ficam com unavailable e own_membership_only, também em sandbox.
Uma aplicação sandbox nunca envia por uma rede, mesmo com a sua própria adesão ligada e com own_membership como estado: as suas transferências vão para a Didit Test VASP.
connected significa que a sua adesão guardada passou a validação local, não que uma troca tenha sido bem-sucedida. A primeira troca em produção confirma-o junto da rede.
O que muda quando uma rede entra em produção
Esta página, o estadonetworks e todas as rotas do diretório mudam em conjunto. Nada muda na sua integração: uma transferência começa a ser encaminhada por uma rede assim que a sua aplicação tiver uma adesão nessa rede, segundo a ordem das vias descrita em Como a Didit encaminha uma troca.
Para pedir acesso a uma rede à qual a Didit ainda não chega, use o cartão Pedir acesso no Marketplace. Cada pedido mostra o seu estado (Aberto, Contactado, Em curso, Ativo ou Recusado), com a nota mais recente da Didit. Quando a Didit altera o estado ou a nota, envia um e-mail ao colega da sua organização que fez o pedido, enquanto ele continuar na sua organização. Um pedido feito com uma chave de API não recebe e-mail, por isso acompanhe-o no Marketplace.
Próximos passos
Travel Rule
O ciclo de vida da troca, as definições, as vias e a API /v3/.
Testar em sandbox
Teste todos os resultados contra a Didit Test VASP antes de passar para produção.
Interoperabilidade
Os endpoints que as VASP contrapartes usam para chegar até si.
Diretório
Encontre uma VASP e as rotas que a sua aplicação pode usar para ela.