Skip to main content

​
KYB-työnkulku

KYB-työnkulku yhdistää nykyiset asiakas-, liittyvän osapuolen, kyky-, tehtävä-, lähetys- ja asiakirjaresurssit yrityksen ja sen omistuksen käytäntötarkasteluun.
KYB-tulokset ja aikataulut ovat käytäntöarvioita. Ne eivät takaa API-siirtymiä, hyväksyntää tai saatavuutta.

​
Nykyinen työnkulkujärjestys

​
1. Luo yritysasiakas

Luo yritysasiakas POST /v3/customers -toiminnolla. Lue nykyinen asiakas GET /v3/customers/{customerId} -toiminnolla.

​
2. Ylläpidä liittyviä osapuolia

Käytä GET /v3/customers/{customerId}/related-parties -toimintoa nykyisten osapuolien tarkasteluun, POST /v3/customers/{customerId}/related-parties -toimintoa uuden luomiseen ja PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} -toimintoa toimitettujen faktojen päivittämiseen. Ylläpidä suoria omistajia, emoyksiköitä, UBO:ita, hallintohenkilöitä, johtajia, toimihenkilöitä ja allekirjoittajia, joita nykyiset tehtävät pyytävät. Heidän roolinsa ovat erilliset.

​
3. Löydä ja pyydä kelvollinen kyky

Lue GET /v3/customers/{customerId}/capabilities/supported. Pyydä käytettävissä olevaa tai beetakykyä vain, kun asiakas on kelvollinen, käyttämällä POST /v3/customers/{customerId}/capabilities/{capabilityId}. Et tarvitse täydellistä omistajaluetteloa ennen kyvyn pyytämistä. Kun kelvollista edunsaajaa ei vielä ole, kyky luodaan silti tilassa restricted avoimin tehtävin, jotka pyytävät omistusrakenteen ja kelvollisen omistajan. Katso edunsaajaa koskeva ennakkoedellytys.

​
4. Lue nykyiset tehtävät

Listaa nykyinen työ GET /v3/customers/{customerId}/tasks -toiminnolla. Hae kukin toimintakelpoinen tehtävä GET /v3/customers/{customerId}/tasks/{taskId} -toiminnolla, johda sitten seuraava toimi sen nykyisestä versiosta, vaatimuksista ja istunnoista.

​
5. Lataa asiakirjoja, joita nykyinen tehtävä pyytää

Lataa pyydetty tiedosto POST /v3/customers/{customerId}/documents -toiminnolla. Nykyinen tehtävä määrittää, onko asiakirja vaadittu, ja voi kaventaa sen hyväksyttyä tyyppiä, määrää tai muotoa.

​
6. Lähetä täydelliset tehtävän vastaukset

Lähetä yksi täydellinen vastausjoukko nykyistä tehtävän versiota varten POST /v3/customers/{customerId}/tasks/{taskId}/submissions -toiminnolla. Käytä nykyisiä vaatimuksen ID:itä ja viittaa ladattuihin asiakirjan ID:ihin vain, kun tehtävä sitä pyytää.

​
7. Seuraa nykyisiä resursseja

Jokaisen toiminnon tai tapahtuman jälkeen hae asiakas GET /v3/customers/{customerId} -toiminnolla, kyky GET /v3/customers/{customerId}/capabilities/{capabilityId} -toiminnolla, sen sovellukset GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications -toiminnolla ja mahdolliset nykyiset tehtävät. Täydellisen mekaniikan osalta katso yrityksen käyttöönotto, Kyvyt ja tehtävät ja Integraatioasiakirjojen opas.

​
Tehostetun huolellisuuden (EDD) laukaisimet

EDD voi olla vaadittu:
  • Korkean riskin lainkäyttöalueilla
  • Korkean riskin vertikaaleilla, mukaan lukien pelaaminen, kauppa ja kryptopörssit
  • Monimutkaisilla omistusrakenteilla
  • Odotetun kuukausittaisen volyymin ylittäessä sovellettavat kynnykset
  • Toiminnalle, joka koskee pakotettuja maita

​
Käytännön tarkastelun tulokset

Tulos: KYB-hyväksyntä, ehdollinen hyväksyntä rajoin tai hylkäys. Nämä ovat käytännön tarkastelun tuloksia, eivät nykyisiä API-tila-arvoja. Ehdollinen käytäntöpäätös voidaan heijastaa nykyisten resurssien kautta luomatta “conditional approval” -nimistä tilaa.

​
Vahvistusaikataulu

Nämä kestot ovat tyypillisiä käytäntöarvioita, eivät taattua API-käyttäytymistä.

​
Yleiset hylkäyssyyt

​
Käytäntötermit ja API-tilat

Pidä käytäntöpäätökset erillään nykyisistä resurssien sanastoista:
  • Kyvyn tila: pending, ready, restricted, rejected, canceled
  • Sovelluksen tila: requested, in_review, action_required, ready, rejected, disabled, canceled
  • Tehtävän tila: action_required, in_review, satisfied, rejected, canceled
  • Lähetyksen tulos: in_review, accepted, changes_requested, rejected
Lue uusin resurssi sen sijaan, että kääntäisit käytäntötuloksen API-arvoksi.