Hvordan utfører jeg automatisert KYC og selskapskontroll av norske selskaper via API?

Hva krever norsk selskapskontroll egentlig?

Start med det denne siden ikke svarer på. Norge har plikter mot hvitvasking som gjelder bestemte typer virksomhet, og de dekker langt mer enn å slå opp et selskap: risikovurdering av kunden, reelle rettighetshavere, løpende oppfølging, interne rutiner og rapportering. Ingenting her forteller deg om disse gjelder for deg, eller om du har oppfylt dem. Regn det som følger som faktalaget om selskapet som en etterlevelsesprosess forbruker, ikke som selve prosessen.

Den andre grensen er selve ordet KYC. Å verifisere at en fysisk person er den vedkommende utgir seg for, er en annen øvelse, som i Norge gjøres med elektronisk ID og ikke med et registeroppslag. Dette API-et svarer på spørsmål om selskapet: finnes det, i hvilken form, er det aktivt, hvem er registrert som i stand til å binde det, og hva har det levert. Der en person dukker opp, dukker vedkommende opp som en registrert rolleinnehaver, som er et faktum om selskapet og ikke en verifisert identitet.

Innenfor det omfanget er den praktiske sjekklisten kort, og hvert punkt svarer til et kall. Identitet og form kommer fra selskapskonteksten. Om enheten er aktiv, konkurs eller under avvikling kommer fra verifiseringskonklusjonen og signalene bak den. Hvem som kan signere kommer fra fullmaktsendepunktet. Finansiell substans, i den begrensede grad åpne data gir den, kommer fra øyeblikksbildet av årsregnskapet.

Hvordan dokumenterer jeg en kontroll for en revisor?

Lagre det som gjør kontrollen reproduserbar, ikke det som får den til å se grundig ut. Hver respons bærer et _meta.response_timestamp som noterer når den forlot linjen, og en _meta.response_hash, en SHA-256 over den kanoniserte responskroppen. Å lagre de to sammen med konklusjonen lar deg senere vise at bytene beslutningen hvilte på er de bytene som ble servert, noe et skjermbilde ikke kan.

Send din egen X-Correlation-ID på hver forespørsel i kontrollen, og lagre den sammen med resultatet. En gyldig UUID v4 gjenbrukes ordrett, og den identifikatoren lagres på tjenersiden på tvers av sporings-, regelevaluerings- og opphavsoppføringene for samme kall. Når en kontrollør spør hva som skjedde en bestemt dato for en bestemt kunde, svarer én identifikator i stedet for en rekonstruksjon fra tidsstempler.

_meta-blokken navngir også data_source, last_verified og legal_basis, slik at opphavet til hvert svar følger svaret. Det betyr mest for feltene du ikke fikk. En respons som sier at det kommersielle nivået ikke var med er vesentlig forskjellig fra en der tallene virkelig ikke finnes, og bare den første er noe du kan løse ved å skaffe en delegering.

Hvordan overvåker jeg en kunde for endringer etter onboarding?

Følg endringsarkivet i stedet for å kjøre onboardingkontrollen på nytt etter en timeplan. Å kontrollere hver kunde månedlig koster i takt med antall kunder og etterlater fortsatt et månedsbredt vindu der du handler på et foreldet svar. Å polle /api/v1/changes med en lagret markør, eller å abonnere med en webhook, koster i takt med hva som faktisk endret seg.

Ranger utløserne etter konsekvens. En rolleendring er den som betyr mest, fordi den kan endre hvem som har rett til å binde selskapet, noe som betyr at et mellomlagret svar om signaturrett nå er tvilsomt og bør slås opp på nytt i stedet for å lappes. Et nysatt flagg for konkurs eller avvikling er det som mest åpenbart endrer om du i det hele tatt bør handle. Et navne- eller adressebytte er som regel en oppdatering av oppføringen og ikke en risikohendelse.

Fordi arkivet bare legger til rader, svarer det også på spørsmålet en kontrollør faktisk stiller, nemlig når du først visste. En korreksjon kommer som en ny rad og ikke som en endring av en gammel, så rekkefølgen av hva som var observerbart og når forblir mulig å gjenskape uten å avhenge av din egen logging. Pollemekanikken er dekket i veiledningen om å hente oppdaterte selskapsdata.

Gjør det første kallet

Sandkasseforespørselen krever ingen nøkkel. TypeScript-snutten kjører verifiserings- og fullmaktskallene under én correlation-id og lagrer dokumentasjonen i stedet for det ferdig viste resultatet.

# Nøkkelløs sandkasse: formen på verifiseringen, syntetisk selskap.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/verify

// Én correlation-id gjennom hele kontrollen gjør den mulig å gjenskape.
const correlationId = crypto.randomUUID();
const headers = {
  Authorization: `Bearer ${process.env.APIER_API_KEY}`,
  "X-Correlation-ID": correlationId,
};
const base = "https://www.apier.no/api/v1/company/999999999";

// Sjekk status før du leser kroppen: en feilkonvolutt har ingen `data`,
// og en halvveis feilet kontroll er verre enn en som feiler høylytt.
const readOk = async (r: Response) => {
  const body = await r.json();
  if (!r.ok) {
    throw new Error(`${body.error_code}: ${body.explanation.summary}`);
  }
  return body;
};

const [verify, authority] = await Promise.all([
  fetch(`${base}/verify`, { headers }).then(readOk),
  fetch(`${base}/authority`, { headers }).then(readOk),
]);

// Lagre hashen og id-en, ikke et skjermbilde av siden.
await recordCheck({
  correlationId,
  verdict: verify.data.verification_status,
  signing: authority.data.classification,
  hash: verify._meta.response_hash,
  servedAt: verify._meta.response_timestamp,
});

Ofte stilte spørsmål

Er dette KYC eller KYB?

KYB, altså verifisering på selskapsnivå. Det fastslår at en virksomhet finnes, hvilken form den har, om den er aktiv, hvem som er registrert som i stand til å opptre for den, og hva den har levert. Det verifiserer ikke identiteten til en fysisk person, som i Norge normalt gjøres med elektronisk ID, og det er en annen øvelse enn foretakets eget etterlevelsesprogram.

Hva kan jeg verifisere om et norsk selskap gjennom et API?

Identitet og organisasjonsform fra Enhetsregisteret, registerstatus og flaggene for konkurs og avvikling, signaturrett og prokura fra de åpne fullmaktsdataene, og innleveringsstatus for årsregnskap fra Regnskapsregisteret. Hver respons navngir kildene sine og oppgir hvor ferske dataene er.

Hvordan dokumenterer jeg overfor en revisor at en kontroll ble gjort?

Lagre correlation-id-en du sendte, responshashen og tidsstempelet på responsen. Hashen er en SHA-256 over den kanoniserte responskroppen, så den viser at bytene du handlet på er de bytene som ble servert. Det er sterkere dokumentasjon enn et lagret skjermbilde, som bare beviser at noe ble vist.

Hvor ofte bør jeg kontrollere en kunde på nytt?

Å kontrollere på nytt etter en timeplan er det dyre svaret, og det går fortsatt glipp av ting mellom kjøringene. Abonner på endringsarkivet i stedet, og reager når noe flytter seg. En rolleendring er den mest verdifulle utløseren, fordi den kan endre hvem som har rett til å binde selskapet og dermed ugyldiggjør et mellomlagret svar om signaturrett.

Gir dette meg juridiske råd om etterlevelse?

Nei. Det returnerer registerfakta med kilder og ferskhet vedheftet, og det er dokumentasjon du kan mate inn i din egen prosess. Hva pliktene dine er, hvilke motparter de gjelder for, og hva som utgjør en tilstrekkelig kontroll i din bransje, er spørsmål for din etterlevelsesfunksjon og dine juridiske rådgivere.