KYC Sense Codi: Creació de Fluxos de Verificació Sense Enginyeria (CA)

Un constructor de fluxos de treball KYC (Know Your Customer) sense codi és una interfície visual per construir, provar i desplegar lògica de verificació d'identitat sense escriure codi. La distinció clau d'un panell de configuració: la programabilitat. La ramificació condicional, les decisions niades, les proves A/B i l'activació de mòduls amb un clic permeten a un equip de compliment expressar la seva política de risc completa visualment, i canviar-la sense un desplegament de codi.

Aquesta distinció és més important del que sembla. Els requisits de compliment canvien. Els llindars de risc es modifiquen. Una nova línia de productes necessita un abast de verificació diferent. Els reguladors actualitzen les directrius. En l'enfocament convencional, cada un d'aquests canvis va a la llista de tasques pendents d'enginyeria i espera un cicle de desplegament. En un model de flux de treball sense codi, el canvi es fa en una Consola, és revisat pel compliment i es posa en marxa el mateix dia.

L'Orquestrador de Fluxos de Treball de Didit és aquesta capa, i és gratuït. Se situa sobre l'API unificada /v3/, que els enginyers truquen una vegada. A partir d'aquest moment, el que fa el flux de verificació és una decisió de producte i compliment, no d'enginyeria.

Punts clau

• Un constructor de fluxos de treball sense codi separa la integració de la configuració. Els enginyers truquen a un punt final de l'API; el compliment construeix i modifica el flux a la Consola sense tocar la integració.
• La ramificació condicional i les decisions niades encaminen els usuaris a diferents conjunts de comprovacions segons el país, el tipus de producte, l'import de la transacció o qualsevol camp disponible en el context de la sessió.
• L'activació de mòduls amb un clic afegeix o elimina qualsevol dels més de 25 mòduls de Didit –document, biometria, AML, correu electrònic, IP, telèfon, validació de bases de dades– d'un flux de treball en segons.
• Les proves A/B en producció executen dos fluxos amb trànsit real, mesuren les taxes de finalització i aprovació per branca, i promouen el guanyador, sense necessitat de canvis de codi.
• Els canvis revisats pel compliment signifiquen que cada modificació d'un flux de treball actiu passa per un pas d'aprovació abans d'afectar els usuaris reals.
• L'Orquestrador de Fluxos de Treball és gratuït. Pagueu per execució de mòduls, per trucada, sense llicències de seient ni tarifes de plataforma.

Què és un constructor de fluxos de treball KYC sense codi

Un flux de treball de verificació és la seqüència de comprovacions per les quals passa un usuari durant l'onboarding, o en un esdeveniment d'escalada posterior en el seu cicle de vida. En el seu estat més simple: escanejar un document d'identificació, fer-se una selfie, fer coincidir la cara amb el document. En el seu estat més complex: un arbre de ramificació on els usuaris de jurisdiccions d'alt risc reben un conjunt de mòduls diferent dels usuaris nacionals, on la mida de la transacció determina quin nivell de liveness s'executa, i on una biometria fallida s'encamina a una cua de revisió en lloc d'un rebuig definitiu.

Un constructor sense codi expressa aquest arbre visualment. Cada node és una condició o un mòdul; cada aresta és una branca. La persona responsable de la política de compliment –no l'enginyer– és la propietària de la lògica. Aquesta separació de propietat és el punt clau: la persona que entén la política de risc ara també la pot canviar directament.

Ramificació condicional i decisions niades

El constructor de fluxos de treball de Didit admet la ramificació multinivell. Un únic flux de treball pot contenir:

Enrutament basat en el país. Els residents de la UE prenen un camí; els residents de LATAM, on s'aplica la validació de bases de dades amb registres locals, prenen un altre. La condició d'enrutament s'avalua en la creació de la sessió des del context de la sessió.

Enrutament basat en el producte. Els comptes de trading requereixen documentació completa més liveness; els comptes d'estalvi s'aproven amb correu electrònic més IP. El mateix usuari, obrint un producte diferent, entra en una branca diferent, tot dins d'un únic flux de treball, un workflow_id, una integració.

Portes d'import de transacció. El primer dipòsit d'un usuari per sota d'un llindar rep una comprovació més lleugera; qualsevol cosa per sobre activa el flux complet. La condició d'import es passa en la càrrega útil de la sessió i és avaluada pel motor.

Enrutament per estat de fallada. Un primer intent biomètric fallit s'encamina a una cua de revisió humana en lloc d'un rebuig definitiu. La branca és una condició sobre el resultat del mòdul, no una integració separada.

Les condicions s'aniden –una condició dins d'una condició– de manera que el mapa de polítiques pot ser tan granular com ho requereixi el negoci. Tot s'expressa en el constructor visual, no en el codi backend.

Activació de mòduls amb un clic

La biblioteca de mòduls de Didit cobreix el cicle complet d'identitat i frau: verificació d'identitat, lectura NFC, liveness passiva, liveness activa, coincidència facial 1:1, cerca facial 1:N, estimació d'edat, cribratge AML (Anti-Money-Laundering), monitorització AML contínua, verificació de correu electrònic, verificació de telèfon, anàlisi d'IP, intel·ligència de dispositius, validació de bases de dades, prova de domicili, qüestionaris personalitzats i molt més.

Al constructor de fluxos de treball, cada mòdul apareix com una targeta. Afegir-lo a un flux de treball és un sol clic. Eliminar-lo és un sol clic. El mòdul es factura per ús quan s'executa, de manera que afegir un mòdul a només una branca significa que només es factura pels usuaris que arriben a aquesta branca.

Això és més important quan les regulacions canvien i s'ha d'afegir una nova comprovació obligatòria a tots els fluxos de treball. En una integració basada en codi, això és un canvi de backend, una revisió, un cicle de desplegament. Al constructor de fluxos de treball, és l'activació del mòdul en els fluxos rellevants a la Consola i l'enviament per a la revisió de compliment. La capa d'integració no es mou.

Proves A/B de fluxos de treball en producció

L'impacte en la conversió de les opcions de disseny de verificació –primer document versus primer selfie, tres passos versus dos, liveness activa versus passiva– sovint és més gran del que s'espera i normalment no es mesura. Les proves A/B integrades de Didit fan que la mesura sigui directa.

Configureu una divisió de trànsit (per exemple, 50/50) entre dues variants de flux de treball. Ambdues s'executen amb usuaris en viu en producció. La Consola mostra la taxa de finalització, la taxa d'aprovació i la distribució de decisions per branca, una al costat de l'altra. Quan tingueu confiança en el guanyador, promocioneu-lo al 100% del trànsit, des de la Consola, sense canvis de codi, amb una revisió de compliment abans de posar-lo en marxa.

El mateix mecanisme s'aplica als canvis impulsats pel compliment. Una nova comprovació obligatòria que s'afegeix es pot provar amb A/B respecte al flux existent per mesurar l'impacte en la conversió abans de la data de desplegament obligatori, proporcionant a l'equip de producte dades en lloc de suposicions.

L'API unificada /v3/: integra una vegada, itera per sempre

L'arquitectura subjacent és el que fa que això sigui pràctic a escala. Cada mòdul, cada branca, cada versió del flux de treball truca a la mateixa superfície de l'API /v3/. Els enginyers truquen a POST /v3/session/ amb un workflow_id i redirigeixen l'usuari a l'URL de la sessió. El motor del flux de treball gestiona la seqüenciació de mòduls, la lògica de ramificació, el lliurament de resultats i l'enviament de webhooks.

Quan el compliment modifica el flux de treball, el workflow_id es manté igual. Res en el costat de l'enginyeria canvia. La integració és estable; la política és activa i mutable.

Això també significa que la mateixa integració admet tots els mòduls futurs que Didit llança. Activació amb un clic des de la Consola, facturada per ús, sense feina de reintegració. Els nous mòduls –validació de bases de dades per a un nou país, un nou nivell de liveness, un nou proveïdor AML– apareixen al constructor i estan disponibles per a qualsevol flux de treball immediatament.

Com que l'Orquestrador de Fluxos de Treball es troba a la mateixa API /v3/ que la Monitorització de Transaccions, una sessió KYC es pot vincular a un perfil de risc de transaccions a la mateixa referència vendor_data. La identitat establerta en l'onboarding flueix directament a la capa de monitorització contínua: una plataforma, una integració.

Casos d'ús

Fintech regulada llançant nous productes. Una nova línia de productes amb un perfil de risc de client diferent necessita un abast de verificació diferent. Construïu una nova branca de flux de treball a la Consola; no cal cap sprint d'enginyeria. El registre d'auditoria captura cada canvi amb la marca de temps i l'autor.

Compliment de VASP i intercanvi de criptomonedes. Les obligacions de la Regla de Viatge de la FATF varien segons la jurisdicció i el tipus de contrapart. Un flux de treball amb ramificació per país i import aplica la política correcta per categoria de transacció sense lògica backend personalitzada per mercat.

Plataformes de mercat amb onboarding a dues bandes. Els comptes de comprador i venedor tenen perfils de risc diferents. Dos fluxos de treball –o dues branques dins d'un– amb diferents conjunts de mòduls, gestionats a la Consola i controlats per versions al registre d'auditoria. Els enginyers van lliurar una integració.

Operadors d'iGaming. Els requisits de joc responsable varien segons la jurisdicció i el segment d'usuari. Les proves A/B de la durada del flux respecte a les taxes de finalització, amb la revisió de compliment que regula cada canvi, és el patró regulador que els reguladors d'Espanya, el Regne Unit i Malta esperen cada vegada més.

Preguntes freqüents

L'Orquestrador de Fluxos de Treball és realment gratuït?

Sí. La lògica d'orquestració, ramificació, proves A/B i activació de mòduls no té cap cost. Pagueu per execució de mòduls, per trucada, sense llicències de seient ni quota de subscripció a la plataforma.

El constructor sense codi substitueix la nostra integració de backend?

No, els enginyers encara truquen a POST /v3/session/ des del vostre backend. El constructor configura el que fa el motor amb aquesta trucada. Elimina la necessitat de reintegrar-se quan la política canvia; no elimina el punt d'integració.

Com funcionen els canvis revisats pel compliment?

Cada modificació d'un flux de treball actiu a la Consola activa un pas de revisió abans que el canvi afecti els usuaris reals. El registre d'auditoria captura qui va canviar què i quan, la qual cosa satisfà la majoria dels requisits de documentació de gestió de canvis reguladors.

Puc combinar el constructor de fluxos de treball amb la monitorització de transaccions?

Sí. Una sessió KYC es vincula a un perfil de monitorització de transaccions mitjançant la mateixa referència vendor_data, de manera que la identitat d'onboarding flueix a la capa de risc de transaccions posterior a l'onboarding sense reintegració. L'estat AWAITING_USER en la monitorització de transaccions pot generar una sessió KYC de remei mitjançant el mateix motor de flux de treball.

Quants mòduls puc combinar en un flux de treball?

No hi ha un límit estricte. Els fluxos de treball poden activar qualsevol combinació dels més de 25 mòduls de Didit, en qualsevol ordre, amb qualsevol profunditat de ramificació que requereixi la política.

Preparat per començar?

• Coneix la funció → Docs
• Veure-ho a la plataforma → Pàgina del producte de verificació d'identitat
• Consulta el preu → Preus – Orquestrador de Fluxos de Treball gratuït, mòduls amb preu per trucada
• Comença gratis → business.didit.me – 500 verificacions gratuïtes/mes