Skip to content
PresenceReady markPresenceReady
Voltar ao blog
·5 min leitura

5 erros de website que causam falhas na due diligence

Estes cinco problemas específicos de website causam consistentemente atrasos e rejeições durante KYB, vendor onboarding e revisões de marketplaces. A maioria pode ser corrigida em menos de uma hora.

due-diligencecompliancekyb
5 erros de website que causam falhas na due diligence

A maioria das falhas de due diligence na camada do website não é causada por algo exótico. São causadas por uma lista curta de lacunas previsíveis e corrigíveis que aparecem em quase todos os sites construídos rapidamente por um fundador que estava a pensar no produto, não na revisão de conformidade.

Os sistemas KYB automatizados de plataformas como TrueBiz, Parcha, Persona, AiPrise e Baselayer tornaram estas verificações consistentes e rápidas. Um crawler é executado antes de um humano olhar para a sua aplicação. O que se segue são os cinco erros de website que aparecem mais frequentemente em revisões falhadas, com a razão específica pela qual cada um é um problema.

Erro 1: Sem email empresarial no seu domínio

Usar um endereço de email pessoal gratuito como Gmail, Outlook, Yahoo, ou qualquer outro como contacto principal para o seu negócio é o sinal mais consistente em sistemas KYB automatizados.

A razão não é que os fornecedores de email gratuitos sejam inerentemente pouco confiáveis. A razão é que um negócio a operar a qualquer escala séria terá configurado email no seu próprio domínio. O esforço necessário é de aproximadamente 15 minutos usando qualquer fornecedor de email principal (Google Workspace, Microsoft 365, Zoho, Fastmail). O custo é de $6 a $12 por mês.

Um negócio que não fez isso ou não sabe que é uma expectativa padrão ou não se preocupou. Ambas as interpretações são negativas do ponto de vista de um verificador.

O que os sistemas automatizados verificam especificamente: os endereços de email visíveis no seu website e na sua aplicação são analisados, o domínio é extraído e é feita uma pesquisa de registo MX contra esse domínio. Se os registos MX apontarem para os servidores pessoais do Gmail do Google em vez dos servidores do Google Workspace, ou se não houver registos MX, isso é um sinal.

A correção: configure o Google Workspace, Microsoft 365 ou um plano de email empresarial equivalente no seu domínio antes de submeter qualquer aplicação. Atualize todas as páginas do seu site que mostram um endereço de email.

Erro 2: Sem páginas legais (ou páginas legais sem conteúdo)

Um website empresarial sem uma política de privacidade, termos de serviço e uma página de contacto com informações reais é lido pelos verificadores — tanto automatizados como humanos — como um site que foi montado para a aplicação, não um site que foi construído para um negócio real em operação.

As páginas legais não são revistas quanto à qualidade legal durante KYB. Elas são verificadas quanto à existência e ao conteúdo mínimo. Uma política de privacidade com três parágrafos que mencionam a recolha de dados, uma página de termos que descreve o serviço e a relação com os utilizadores, e uma página de contacto com um email de domínio e um endereço físico ou registado são tipicamente suficientes para passar na verificação automatizada.

O que falha comumente: um site que tem um link no rodapé rotulado como "Privacidade" que resulta em 404, ou uma página de privacidade com a única linha "Não recolhemos os seus dados," ou uma página de termos que é idêntica a um modelo genérico que não menciona o negócio pelo nome. Os crawlers automatizados analisam a página e pontuam com base na contagem de palavras, presença de palavras-chave e se o nome da empresa aparece no conteúdo.

A correção: instale páginas legais reais antes de aplicar. Elas não precisam ser redigidas por um advogado para passar na verificação web, embora devam ser legalmente apropriadas para a sua jurisdição se estiver realmente a recolher dados de utilizadores. Serviços como Termly, GetTerms ou iubenda geram modelos compatíveis em minutos.

Erro 3: Uma página Sobre sem nomes reais, sem equipa real, sem história real

A página Sobre é frequentemente onde os revisores humanos passam mais tempo durante uma retenção manual. É a página que responde: quem são as pessoas reais por trás deste negócio.

Uma página Sobre genérica — "Somos uma equipa de profissionais apaixonados dedicados a entregar valor" — sem nomes, sem fotos, sem antecedentes profissionais e sem história de fundação não responde a essa pergunta. Executa a forma de uma página Sobre sem fornecer a substância.

Os sistemas automatizados também verificam a página Sobre. Procuram indivíduos nomeados, títulos e contexto biográfico. Persona e AiPrise, em particular, cruzam referências de nomes encontrados no site contra bases de dados profissionais para confirmar que os indivíduos identificados existem e têm histórias profissionais relevantes.

O que falha: uma página Sobre que descreve a missão da empresa sem nomear ninguém, uma seção de equipa com fotos de stock rotuladas "Nosso CEO" e "Nosso CTO" sem nomes, e páginas que foram claramente escritas antes de a empresa ter uma equipa de liderança e nunca foram atualizadas.

A correção: nomeie os fundadores ou o operador principal. Inclua um parágrafo de antecedentes profissionais. Ligue a um perfil do LinkedIn. Uma única pessoa real com um nome real e uma história profissional credível na sua página Sobre vale mais do que qualquer quantidade de linguagem corporativa sobre missão e valores.

Erro 4: Sem página de contacto, ou uma página de contacto com apenas um Gmail pessoal

A página de contacto é o canal através do qual um verificador testará se o seu negócio realmente responde. Durante a revisão manual, algumas equipas de conformidade enviam um email de teste ou preenchem o formulário de contacto.

Uma página de contacto em falta é um sinal vermelho automático. Uma página de contacto que mostra apenas um endereço Gmail (ou apenas um formulário de contacto sem email visível) é uma versão mais fraca do mesmo problema. Uma página de contacto que mostra um endereço de email de domínio, um endereço físico ou virtual de escritório, e opcionalmente um número de telefone é o que o verificador espera encontrar.

O que os sistemas automatizados verificam especificamente: a página de contacto é analisada, todos os endereços de email encontrados nela são analisados, e os domínios são extraídos. Uma página que mostra yourbusiness@gmail.com falhará na verificação de email de domínio. Uma página que não mostra email nenhum — apenas um formulário — depende de como o sistema está configurado, mas geralmente é pontuada mais baixo do que uma página com um email de domínio visível.

A correção: crie uma página /contact. Mostre o seu endereço de email de domínio de forma proeminente. Inclua o endereço da empresa (endereço registado é aceitável). Se tiver um número de telefone, inclua-o. Teste o formulário se tiver um.

Erro 5: O website contradiz as suas informações de registo

Esta é a falha que causa os atrasos mais longos porque requer mudanças reais e depois uma nova revisão em vez de apenas a submissão de documentos.

Contradições comuns: o nome da entidade legal na aplicação é "Larrazabal Consulting LLC" mas o website diz "Larrazabal" em todo o lado e nunca divulga o nome legal completo. O estado na aplicação é Delaware mas o website diz "Baseado na Califórnia." A categoria de negócio na aplicação é "desenvolvimento de software" mas o website só fala sobre serviços de marketing. O endereço na aplicação é um escritório virtual em Nova Iorque mas o rodapé do website mostra um endereço de rua em Miami.

Os sistemas automatizados que cruzam referências de pontos de dados — Middesk e Baselayer são particularmente minuciosos nisto — irão sinalizar qualquer uma destas discrepâncias e encaminhar a aplicação para revisão manual. Os revisores humanos então pedirão uma explicação. A explicação leva tempo, gera idas e vindas, e às vezes resulta em uma negação se o revisor concluir que as discrepâncias sugerem má representação.

A correção: antes de submeter qualquer aplicação, audite o seu website contra três pontos de dados. Primeiro, o nome legal exato conforme registado no seu estado. Segundo, a atividade empresarial conforme descrita na aplicação. Terceiro, o endereço e jurisdição conforme aparecem nos seus documentos de registo. Atualize o website para corresponder a todos os três antes de aplicar.

Porque estes erros são tão comuns

Estes cinco problemas partilham uma causa raiz: o website foi construído para descrever o negócio a potenciais clientes, não para satisfazer um revisor de conformidade. São públicos diferentes com prioridades diferentes.

Um cliente preocupa-se se o seu produto resolve o problema deles. Um revisor KYB preocupa-se se o seu negócio é real, consistente e opera legalmente. A linguagem, as páginas e os sinais que servem um público não servem automaticamente o outro.

A PresenceReady constrói websites empresariais especificamente para o público de conformidade. A estrutura, as páginas e o conteúdo são calibrados contra o que os sistemas KYB automatizados verificam e o que os revisores humanos procuram durante retenções manuais. Os cinco pontos de falha acima são tratados na configuração padrão.

Se o seu website tiver alguma destas lacunas e estiver prestes a aplicar ao Mercury, Brex, Relay, Wise, Stripe Atlas, ou qualquer outra plataforma com um requisito KYB, corrija-os antes de submeter. Os dias que perde com uma retenção manual são tipicamente muito mais caros do que as horas que leva para resolver os problemas subjacentes.

Este artigo é informativo e não constitui aconselhamento jurídico, fiscal ou de compliance. A PresenceReady não garante decisões de aprovação de terceiros.