> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Redes da Travel Rule e o seu estado > Alcance atual de cada rede e canal da Travel Rule, o que exige do seu lado e o que aguarda uma adesão que a Didit ainda não tem. Uma troca da [Travel Rule](https://docs.didit.me/pt/transaction-monitoring/travel-rule.md) chega à VASP contraparte através de um único canal. Três canais não exigem a adesão de ninguém: `INTERNAL` 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. > [!WARNING] > > **A Didit ainda não tem uma adesão ativa a nenhuma rede Travel Rule.** Um canal de rede só funciona hoje com uma adesão que o próprio utilizador liga na **Marketplace** da consola. Nada chega a uma contraparte em GTR, TRUST, VerifyVASP ou Sygna Bridge através da adesão própria da Didit, e esta página será alterada no dia em que isso mudar. ## Estado em resumo | Canal | O que é necessário | Envio para uma contraparte | Receção de uma contraparte | | - | - | - | - | | `INTERNAL` | Nada | Funciona | Funciona | | `TRP` | Nada | Funciona quando a contraparte responde de imediato | Ainda não disponível | | `EMAIL` | Um endereço de conformidade | Funciona | Não é um canal de receção | | `GTR` | A sua própria adesão | Implementado, ainda não comprovado em funcionamento | Ainda não ativado | | `VERIFYVASP` | A sua própria adesão | Implementado, ainda não comprovado em funcionamento | Ainda não ativado | | `SYGNA` | A sua própria adesão | Implementado, ainda não comprovado em funcionamento | Ainda não ativado | | `TRUST` | A sua própria adesão | Envia apenas, nunca conclui | Não disponível | | CODE, TRISA, Notabene, Veriscope | - | Não integrado | Não integrado | "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](https://docs.didit.me/pt/transaction-monitoring/travel-rule.md#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](https://docs.didit.me/pt/transaction-monitoring/travel-rule.md#enviar-uma-transferência). ### TRP A Didit implementa nativamente o protocolo Travel Rule. Uma transferência segue por `TRP` 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 com `action: "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. O host TRP público da Didit ainda não disponibiliza estes endpoints. A [interoperabilidade do Travel Rule](https://docs.didit.me/pt/transaction-monitoring/travel-rule-interoperability.md) documenta os endpoints que as contrapartes chamam quando isso acontecer. ### EMAIL Quando nenhum protocolo chega à contraparte, a Didit envia aos endereços de conformidade dela uma ligação de utilização única para uma página alojada onde podem aceitar ou recusar. Não é necessária qualquer conta nem integração do lado deles. Consulte [Recolha por e-mail](https://docs.didit.me/pt/transaction-monitoring/travel-rule.md#recolha-por-e-mail-para-contrapartes-inacessíveis). ## 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. | Rede | O que pede o Marketplace | Como a resposta da contraparte chega à Didit | | - | - | - | | `GTR` | URL base da API, código VASP da GTR, chave de acesso, chave secreta e a chave privada ed25519 (base64) cuja chave pública está registada no portal da GTR | Na resposta da GTR ao pedido, ou consultando o estado do pedido a cada 5 minutos enquanto a transferência aguarda | | `VERIFYVASP` | O URL do seu próprio Enclave VerifyVASP, o seu ID VerifyVASP e o token que o seu Enclave apresenta à Didit | Consultando o estado da verificação a cada 5 minutos | | `SYGNA` | Código VASP da Sygna, chave de API e chave privada de assinatura. O URL base da API é opcional: deixe-o em branco para usar a Sygna Bridge de produção | Consultando o estado da transferência a cada 5 minutos. O callback de permissão da Sygna aponta para o host TRP público da Didit, que ainda não está ativo, pelo que a consulta é, por agora, a única forma de a resposta chegar à Didit | | `TRUST` | URL base, ID de membro TRUST e chave de API. Uma chave privada de cifragem X25519 (hex) é opcional | Nunca: a TRUST não envia nada que a Didit possa ler, pelo que uma transferência entregue fica à espera até ao prazo expirar | 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`, `429` ou `5xx`): após 30 segundos, depois 2, 10, 30 e 60 minutos. Após a sexta tentativa falhada, a transferência passa a `COUNTERPARTY_VASP_NOT_REACHABLE`. Uma recusa, como outra resposta `4xx` ou um redirecionamento, não é repetida: a transferência passa de imediato a `COUNTERPARTY_VASP_NOT_REACHABLE`. * Uma transferência cuja resposta nunca chega fica em `AWAITING_COUNTERPARTY` até passar `confirmation_timeout_hours`; depois expira e aplica o seu `timeout_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 `400` quando 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 devolvem `403` 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: | `state` | `reason` | Significado | | - | - | - | | `own_membership` | `own_membership_connected` | Ligou a sua própria adesão. Numa aplicação em produção, é a sua adesão que envia por si. | | `live_through_didit` | `participant_active` | A adesão da Didit inclui a sua aplicação como o seu próprio participante ativo. | | `off` | `platform_network_switched_off` | Desativou a rede em `disabled_networks`. | | `didit_onboarding` | `didit_membership_not_live` | A adesão da Didit a esta rede ainda não está em produção. | | `questionnaire_needed` | `questionnaire_not_submitted`, `questionnaire_changes_requested` | O questionário da Didit para a rede não foi submetido, ou a Didit pediu alterações. | | `questionnaire_in_review` | `questionnaire_submitted` | A Didit está a analisar o seu questionário. | | `request_access` | `participant_not_requested` | O seu questionário foi aprovado: peça acesso à rede. | | `request_sent` | `questionnaire_pending`, `submitted_to_network` | O seu pedido aguarda que a Didit o registe, ou o onboarding da rede. | | `unavailable` | `own_membership_only`, `sandbox_application`, `questionnaire_rejected`, `participant_suspended`, `participant_rejected` | Não é possível enviar nada por esta rede em nome da sua aplicação: a TRUST e a VerifyVASP só são acedidas com a sua própria adesão, a Didit nunca regista uma aplicação sandbox numa rede, a Didit recusou o seu questionário, ou a rede suspendeu ou recusou o seu participante. | | `error` | `provisioning_failed`, `participant_key_missing`, `participant_key_unresolved` | A rede recusou o seu registo, ou falta a chave de que o seu participante precisa. Pedir acesso à rede novamente volta a tentar. | `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](https://docs.didit.me/pt/transaction-monitoring/travel-rule-sandbox.md). `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 estado `networks` 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](https://docs.didit.me/pt/transaction-monitoring/travel-rule-interoperability.md#como-a-didit-encaminha-uma-transferência). 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 > [card] [Travel Rule](https://docs.didit.me/pt/transaction-monitoring/travel-rule.md) > > O ciclo de vida da troca, as definições, as vias e a API /v3/. > [card] [Testar em sandbox](https://docs.didit.me/pt/transaction-monitoring/travel-rule-sandbox.md) > > Teste todos os resultados contra a Didit Test VASP antes de passar para produção. > [card] [Interoperabilidade](https://docs.didit.me/pt/transaction-monitoring/travel-rule-interoperability.md) > > Os endpoints que as VASP contrapartes usam para chegar até si. > [card] [Diretório](https://docs.didit.me/pt/transaction-monitoring/travel-rule.md#diretório) > > Encontre uma VASP e as rotas que a sua aplicação pode usar para ela. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.