Skip to content
PresenceReady markPresenceReady
Torna al blog
·5 min lettura

5 errori del sito web che causano fallimenti nella due diligence

Questi cinque problemi specifici del sito web causano costantemente ritardi e rifiuti durante KYB, vendor onboarding e revisioni di marketplace. La maggior parte può essere risolta in meno di un'ora.

due-diligencecompliancekyb
5 errori del sito web che causano fallimenti nella due diligence

La maggior parte dei fallimenti nella due diligence a livello di sito web non è causata da qualcosa di esotico. Sono causati da un breve elenco di lacune prevedibili e risolvibili che appaiono su quasi ogni sito costruito rapidamente da un fondatore che pensava al prodotto, non alla revisione della compliance.

I sistemi KYB automatizzati di piattaforme come TrueBiz, Parcha, Persona, AiPrise e Baselayer hanno reso questi controlli coerenti e rapidi. Un crawler viene eseguito prima che un essere umano esamini la tua applicazione. Di seguito sono riportati i cinque errori del sito web che appaiono più spesso nelle revisioni fallite, con il motivo specifico per cui ciascuno è un problema.

Errore 1: Nessuna email aziendale sul tuo dominio

Utilizzare un indirizzo email personale gratuito come Gmail, Outlook, Yahoo o altri come contatto principale per la tua azienda è il segnale più costante nei sistemi KYB automatizzati.

Il motivo non è che i provider di email gratuiti siano intrinsecamente inaffidabili. Il motivo è che un'azienda che opera a qualsiasi scala seria avrà configurato l'email sul proprio dominio. Lo sforzo richiesto è di circa 15 minuti utilizzando qualsiasi principale provider di email (Google Workspace, Microsoft 365, Zoho, Fastmail). Il costo è di $6 a $12 al mese.

Un'azienda che non ha fatto questo o non sa che è una aspettativa standard o non si è preoccupata. Entrambe le interpretazioni sono negative dal punto di vista di un verificatore.

Cosa controllano specificamente i sistemi automatizzati: gli indirizzi email visibili sul tuo sito web e nella tua applicazione vengono analizzati, il dominio viene estratto e viene eseguita una ricerca del record MX su quel dominio. Se i record MX puntano ai server Gmail personali di Google anziché ai server di Google Workspace, o se non ci sono record MX, questo è un segnale.

La soluzione: configura Google Workspace, Microsoft 365 o un piano email aziendale equivalente sul tuo dominio prima di inviare qualsiasi applicazione. Aggiorna ogni pagina del tuo sito che mostra un indirizzo email.

Errore 2: Nessuna pagina legale (o pagine legali senza contenuto)

Un sito web aziendale senza una privacy policy, termini di servizio e una pagina di contatto con informazioni reali viene letto dai verificatori — sia automatizzati che umani — come un sito assemblato per l'applicazione, non un sito costruito per un'azienda operativa reale.

Le pagine legali non vengono esaminate per la qualità legale durante KYB. Vengono controllate per l'esistenza e per il contenuto minimo. Una privacy policy con tre paragrafi che menzionano la raccolta dei dati, una pagina dei termini che descrive il servizio e la relazione con gli utenti, e una pagina di contatto con un'email di dominio e un indirizzo fisico o registrato sono tipicamente sufficienti per superare il controllo automatizzato.

Cosa fallisce comunemente: un sito che ha un link nel footer etichettato "Privacy" che restituisce un errore 404, o una pagina di privacy con la singola riga "Non raccogliamo i tuoi dati", o una pagina dei termini identica a un modello generico che non menziona l'azienda per nome. I crawler automatizzati analizzano la pagina e valutano in base al conteggio delle parole, alla presenza di parole chiave e se il nome dell'azienda appare nel contenuto.

La soluzione: installa pagine legali reali prima di applicare. Non devono essere redatte da un avvocato per superare il controllo web, anche se dovrebbero essere legalmente appropriate per la tua giurisdizione se stai effettivamente raccogliendo dati degli utenti. Servizi come Termly, GetTerms o iubenda generano modelli conformi in pochi minuti.

Errore 3: Una pagina "Chi siamo" senza nomi reali, senza team reale, senza storia reale

La pagina "Chi siamo" è spesso dove i revisori umani trascorrono più tempo durante una sospensione manuale. È la pagina che risponde: chi sono le persone reali dietro questa azienda.

Una pagina "Chi siamo" generica — "Siamo un team di professionisti appassionati dedicati a fornire valore" — senza nomi, senza foto, senza background professionali e senza storia di fondazione non risponde a quella domanda. Esegue la forma di una pagina "Chi siamo" senza fornire la sostanza.

Anche i sistemi automatizzati controllano la pagina "Chi siamo". Cercano individui nominati, titoli e contesto biografico. Persona e AiPrise, in particolare, incrociano i nomi trovati sul sito con database professionali per confermare che gli individui identificati esistono e hanno storie professionali rilevanti.

Cosa fallisce: una pagina "Chi siamo" che descrive la missione dell'azienda senza nominare nessuno, una sezione del team con foto stock etichettate "Il nostro CEO" e "Il nostro CTO" senza nomi, e pagine che sono state chiaramente scritte prima che l'azienda avesse un team di leadership e non sono mai state aggiornate.

La soluzione: nomina i fondatori o l'operatore principale. Includi un background professionale di un paragrafo. Collega un profilo LinkedIn. Una singola persona reale con un nome reale e una storia professionale credibile sulla tua pagina "Chi siamo" vale più di qualsiasi quantità di linguaggio aziendale su missione e valori.

Errore 4: Nessuna pagina di contatto, o una pagina di contatto con solo un Gmail personale

La pagina di contatto è il canale attraverso il quale un verificatore testerà se la tua azienda risponde effettivamente. Durante la revisione manuale, alcuni team di compliance inviano un'email di prova o compilano il modulo di contatto.

Una pagina di contatto mancante è un segnale rosso automatico. Una pagina di contatto che mostra solo un indirizzo Gmail (o solo un modulo di contatto senza email visibile) è una versione più debole dello stesso problema. Una pagina di contatto che mostra un indirizzo email di dominio, un indirizzo fisico o virtuale e opzionalmente un numero di telefono è ciò che il verificatore si aspetta di trovare.

Cosa controllano specificamente i sistemi automatizzati: la pagina di contatto viene analizzata, tutti gli indirizzi email trovati su di essa vengono analizzati e i domini vengono estratti. Una pagina che mostra yourbusiness@gmail.com fallirà il controllo dell'email di dominio. Una pagina che non mostra alcuna email — solo un modulo — dipende da come è configurato il sistema, ma generalmente è valutata più bassa di una pagina con un'email di dominio visibile.

La soluzione: crea una pagina /contact. Mostra chiaramente il tuo indirizzo email di dominio. Includi l'indirizzo dell'azienda (l'indirizzo registrato è accettabile). Se hai un numero di telefono, includilo. Testa il modulo se ne hai uno.

Errore 5: Il sito web contraddice le informazioni di registrazione

Questo è il fallimento che causa i ritardi più lunghi perché richiede effettivamente modifiche e poi una nuova revisione piuttosto che solo la presentazione di documenti.

Contraddizioni comuni: il nome dell'entità legale sull'applicazione è "Larrazabal Consulting LLC" ma il sito web dice "Larrazabal" ovunque e non rivela mai il nome legale completo. Lo stato sull'applicazione è Delaware ma il sito web dice "Basato in California." La categoria aziendale sull'applicazione è "sviluppo software" ma il sito web parla solo di servizi di marketing. L'indirizzo sull'applicazione è un ufficio virtuale di New York ma il footer del sito web mostra un indirizzo di strada a Miami.

I sistemi automatizzati che incrociano i punti dati — Middesk e Baselayer sono particolarmente accurati in questo — segnaleranno qualsiasi di queste discrepanze e indirizzeranno l'applicazione a una revisione manuale. I revisori umani chiederanno quindi una spiegazione. L'esplicazione richiede tempo, genera scambi di comunicazioni e a volte risulta in un rifiuto se il revisore conclude che le discrepanze suggeriscono una falsa rappresentazione.

La soluzione: prima di inviare qualsiasi applicazione, verifica il tuo sito web rispetto a tre punti dati. Primo, il nome legale esatto come depositato presso il tuo stato. Secondo, l'attività aziendale come l'hai descritta nell'applicazione. Terzo, l'indirizzo e la giurisdizione come appaiono nei tuoi documenti di registrazione. Aggiorna il sito web per far corrispondere tutti e tre prima di applicare.

Perché questi errori sono così comuni

Questi cinque problemi condividono una causa radice: il sito web è stato costruito per descrivere l'azienda ai potenziali clienti, non per soddisfare un revisore della compliance. Sono pubblici diversi con priorità diverse.

Un cliente si preoccupa se il tuo prodotto risolve il loro problema. Un revisore KYB si preoccupa se la tua azienda è reale, coerente e operante legalmente. Il linguaggio, le pagine e i segnali che servono un pubblico non servono automaticamente l'altro.

PresenceReady costruisce siti web aziendali specificamente per il pubblico della compliance. La struttura, le pagine e il contenuto sono calibrati rispetto a ciò che i sistemi KYB automatizzati controllano e ciò che i revisori umani cercano durante le sospensioni manuali. I cinque punti di fallimento sopra sono gestiti nella configurazione standard.

Se il tuo sito web ha una di queste lacune e stai per applicare a Mercury, Brex, Relay, Wise, Stripe Atlas o qualsiasi altra piattaforma con un requisito KYB, correggile prima di inviare. I giorni che perdi per una sospensione manuale sono tipicamente molto più costosi delle ore necessarie per affrontare i problemi sottostanti.

Questo articolo è informativo e non costituisce consulenza legale, fiscale o di compliance. PresenceReady non garantisce le decisioni di approvazione di terzi.