Organisations-KYC/KYB/IDV-Integration
Schritt 5 der Quickstart nennt zwei harte Gates für Live-Traffic: ein freigegebenes Organisations-KYC und ein aufgeladenes Guthaben. Organisations-KYC ist eine einmalige Prüfung pro Workspace — sie verifiziert das Unternehmen selbst, nicht seine Rufnummern (die per-Rufnummer-Dokumentbündel sind ein separater Punkt; vergleichen Sie am Ende). Der Guide behandelt die volle Schleife — Einreichung, optionale gehostete Identitätsprüfung, Abfrage des Ergebnisses, erneute Einreichung bei Ablehnung — danach die übrigen Go-live-Gates.1. Warum Live-Traffic blockiert ist
Live-Sends bleiben eingeschränkt, bis ein Mitglied des Devotel-Betriebteams ein tatsächliches Unternehmenprofil geprüft hat. Bis die Freigabe vorliegt:- Rufnummern kaufen bleibt möglich, aber kein SMS-, WhatsApp- oder Sprachverkehr verlässt die Plattform.
- Das Dashboard zeigt den Status in einem Banner; die hier behandelte Seite ist unter Einstellungen → KYC erreichbar.
not_started bedeutet, das Formular wurde nie eingereicht. pending_review bedeutet, eine Operator-Warteschlange hält die Einreichung (der E-Mail-Bestätigungs-Webhook stellt dies am Signup vor; das Formular unten ersetzt es durch reiche Details). Nach einer Entscheidung erhalten Sie approved oder rejected.
2. Reichen Sie das Formular ein
POST auf/api/v1/organization/kyc/submit mit dem Unternehmenprofil. Der API prüft: Firmenname und Land erforderlich, Website optional, Verwendungsbeschreibung mindestens zehn Zeichen, optional bis zu 20 beneficial-owner-Einträge.
pending_review und gibt den gespeicherten Datensatz plus das Screening-Verdict zurück — die Prüfung ist menschlich, nichts wird automatisch freigegeben oder abgelehnt.
Antwort (200):
data.kyb ist das Unternehmen-Screening (clear wenn die Entity clean ist, review wenn eine sankktionierte Region oder eine verweigerte Partei gepasst hat). Es wird mit dem Formular geprüft — blockiert die Einreichung nie und erfordert auch bei review dieselbe menschliche Prüfung. Das Feld fehlt, wenn das Screening nicht laufen konnte (dann wird eine manuelle Überprüfung angemeldet).
3. Marktpayloads — was Ihre Destination tatsächlich verlangt
Das obige Formular wird pro Organisation einmal eingereicht, doch welche Felder der Prüfer am stärksten gewichtet, hängt von der Destination ab. Dascountry verankert den Markt — geben Sie ihn als Zielmarkt ein, nicht als Rechnungsadresse; ein UK-Sender mit country: "US" erhält nur eine Rückfrage zur Korrektur. Zwei Feldgruppen erreichen stets den Prüfer: das Freitext use_case und die KYB-Identitätsfelder (registration_number, beneficial_owners). Organisationen, die mehrere blockierte Destinationen bedienen, wiederholen das Dokumentmodell pro Destination — gruppieren Sie Uploads pro Ziel in der Dokumentenbibliothek, statt ein Formular zu verwässern.
Die folgenden Märkte halten Sends vor einer Vorregistrierung. Für jeden: die hervorzuhebenden Profilfelder und die geforderten Dokumentrollen. Uploads liegen unter Compliance → Dokumente und werden per ID in Registrierungen referenziert; die prüfersichtbaren Rollen sind business_doc, address_proof, id_proof, authorization. Die Sender-ID-Marktmatrix nennt den live-Wert registration pro Land; der Documents Guide deckt den Uploadfluss ab.
Deutschland — BNetzA Entity-Identität
BNetzA (Bundesnetzagentur) prüft die Identität hinter jeder alphabetyptischen Route und jeder Voice-KYC. Gewichten Sieregistration_number (Handelsregistereintrag) und eine richtige Rechtsform. Geforderte Dokumente: business_doc (Handelsregisterauszug).
Spanien — CNMC Sender-ID-Registrierung
Die CNMC erlaubt Sends auf alphabetyptischen Sendern erst nach Registrierung. Gewichten Sieregistration_number und ein use_case auf spanische Empfänger ausgelegt. Dokumente: business_doc (CIF/NIF der Entität).
Frankreich — ARCEP Absender-Registrierung
Die ARCEP und die Träger registreren die Identität hinter dem alphabetyptischen Sender; nicht angemeldete Marken erhalten SMS-Routen-Ablehnungen. Gewichten Sieregistration_number (RCS-Immatrikulation) mit einem referenziertem use_case. Dokumente: business_doc (Kbis-Extrakt oder SIREN) plus authorization, wenn eine Agentur im Namen der Marke einreicht.
Türkei — BTK Sender-Name
Die BTK registriert den Absendernamen, nicht nur die Route — hinterlegen Sie den Namen, den Ihre Kunden sehen, und nennen Sie ihn inuse_case. Dokumente: business_doc (Handelskammer-Dokumente).
Arabische Märkte — Beispiel VAE TDRA
Einige arabische Märkte (z. B. VAE, TDRA plus Träger e&/du) erwarten eine KYC-abgesicherte Markenidentität am Absender — der Overlay, der dünnen Einreichungen am ehesten abschwirrt. Gewichten Siecompany_name, company_website und ein vollständiges use_case. Dokumente: business_doc plus Marken-authorization.
In jedem Markt gilt dasselbe: Entscheiden Sie, was in company_name, use_case und registration_number steht, bevor ein Sende-Gate den Traffic mit einer 422 abwehrt. Send Gates erläutert, wie eine required-Destination unregistrierte Sends blockiert. Für die Lesart englischer oder historisch englischer Märkte (UK, Saudi-Arabien, VAE, Brasilien, Indien DLT, US 10DLC) siehe die englische Version des Guides.
4. Optional: eine gehostete IDV-Session hinzufügen
Einige Träger verlangen ein staatliches Ausweisdokument plus einen Liveness-Check vor der Unterzeichnung. POST/api/v1/organization/kyc/idv/session öffnet eine gehostete Session beim konfigurierten Provider; öffnen Sie die zurückgegebene URL im Browser oder geben Sie sie an den Unterzeichner.
cURL
503:
GET /api/v1/organization/kyc/idv/status. Er reconciliiert sich selbst: solange die gespeicherte Session pending ist, fragt jeder GET den Provider nach dem neuesten Ergebnis und schreibt die finale Transition zurück. Ein finales verified, declined oder expired — mit einem reason falls der Provider eines liefert — ergänzt das Signal, das der Operator abwägt. Es ist niemals selbstanerkennend: verified genehmigt KYC NICHT, und declined lehnt es nicht ab.
5. Erfragen Sie das Organisations-Verdict
PollGET /api/v1/organization/kyc/status bis das Organ-Verdict anliegt. Die möglichen Stände sind not_started, pending (pre-submit transient), pending_review, approved und rejected; die Antwort spiegelt auch die eingereichten Unternehmensfelder und reviewed_at nach einer Entscheidung.
cURL
GET /api/v1/organization/kyc-Pfad; er liefert das gleiche Antwortschema, also ist ein Ziel auf /kyc/status sicher und kompatibel.
Der Endpoint ist sicher vom Dashboard oder einem Server abzupollern — er degradiert bei einem kurzen Datenbankblip zu einer neutralen not_started-Lesung statt einer 503, und die nächste Abfrage korrigiert sich selbst.
6. Erneute Einreichung und die «ALREADY_VERIFIED»-Grenze
Ein erneutes POST des Formulars ist bei einemrejected die richtige Wahl: der Schreibzugriff stempelt pending_review erneut, überschreibt den Formularblock und durchläuft das Screening mit den korrigierten Antworten. Auch eine noch pending_review erneute Einreichung wird akzeptiert — sie ersetzt den laufenden Profil.
Eine approved Organisation erneut zu einzureichen ergibt 409:
verified ist — ein POST auf den Session-Endpunkt erhält dann 409 ALREADY_VERIFIED, und eine erneute Erfassung ist nur sinnvoll, wenn die Organisation abgelehnt wurde und erneut angetrieben wird.
7. Was eine Ablehnung bedeutet und was zu tun ist
Eine Ablehnung ist ein menschliches Urteil — der Operator geht das Devotel-Betriebspanel durch, liest Ihre Formularfelder plus die screening- und IDV-Signale und drückt Approve oder Reject. Die kundenorientierte Oberfläche legt nie ein Maschinenrationale frei; die Entscheidungsemail nennt die Lücke und die Korrektur. Behandeln Sierejected als handlungsrelevante Lesart:
- Lesen Sie die eingereichten Felder erneut auf Genauigkeit (eine Diskrepanz beim legalen Namen oder ein dünnes use-case ist das häufigste Flag).
- Beheben Sie alle
kyb-Matches und jeglichedeclined-IDV-Ergebnisse. - Reichen Sie mit den korrigierten Daten erneut ein — der Endpoint akzeptiert und die Warteschlange re-organisiert sich.
req_*-ID aus der Statusabfrage; der Eigentümer der Review-Warteschlange kann den Vorgang wieder öffnen und operatorseitig freigeben.
Was dieses Gate NICHT ist: per-Rufnummer-Dokumente
Organisations-KYC steht neben den per-Rufnummer-Dokumentbündeln, die Träger pro Sender fordern — letztere (Firmentstellung, Adressnachweis, Identität) decken eine bestimmte, von Ihnen gehaltene Nummer und folgen einer separaten Prüfschleife unter Compliance → Dokumente. Die Genehmigung der Organisation klärt ein per-Rufnummer-Paket nicht, und umgekehrt. Siehe den per-Rufnummer-KYC-Dokumente-Guide für diesen separaten Register.8. Nach Freigabe — die letzten Go-live-Gates
Freigabe kippt das Organ-Verdict, also liefertGET /organization/kyc/status approved. Schließen Sie die beiden verbleibenden Gates aus der Go-live-Checkliste ab:
- Live-Key anzelms. Unter Einstellungen → API Keys einen geheim mit dem Präfix
dv_live_sk_erstellen und den Sandbox-Schlüsseldv_test_sk_ersetzen — Requestformen sind identisch, also ist kein Code-Umbau nötig. - Guthaben aufladen. Fügen Sie Mittel unter Einstellungen → Billing hinzu; SMS, WhatsApp und Voice ziehen alle von diesem Wallet, und Live-Sends schlagen bei leerem Guthaben mit einer Billing-Fehlermeldung fehl.
- US-SMS: 10DLC hinzufügen. Enthält die Destination US-Long-Codes, schließen Sie die 10DLC-Marken- + Kampagnen-Registration ab. Die KYC-Freigabe allein ersetzt die Carrier-Registrierung nie; beide Gates müssen vor einem US-SMS-Send grün sein.
Verwandte Referenzen
- Go-live-Checkliste — die harten Gates vor dem Live-Traffic.
- Sender-ID Registration — länderspezifische Registrierungen, die auf
doc_-IDs verwiesen werden. - Per-Rufnummer-KYC-Dokumente — die tenant-eigene Dokumentenbibliothek.