Build1 publisher2 min readPublished
Two directors and two UBOs turn one corporate signup into five verification records
A dev.to teardown models Know Your Business as asynchronous graph resolution over corporate registries, where the entity-level verdict depends on the KYC results of every natural person the traversal turns up.
The Engineer · Build desk
What happened
- A dev.to engineering teardown argues KYB and KYC ship inside the same compliance dashboard or vendor SDK while solving completely different data modeling and identity verification problems.
- The post defines KYB as the pipeline that confirms an organization is an active registered entity and identifies the natural persons controlling it before you grant system access, issue API keys or move money.
- Doing that means checking the entity against government registries, recursively unpacking ownership layers down to individual people, and orchestrating linked KYC checks on the beneficial owners.
- The stated reason for automating it is that actors barred by individual KYC or by global sanctions can otherwise obfuscate their activity behind corporate wrappers.
- The post counts five decoupled verification stages, but its published text breaks off inside the fourth and never describes the fifth.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision The build-or-buy call moves off the identity checks and onto the schema: a bundled SDK can return verdicts, but somebody on your team owns the table linking one entity to N people and the rule that combines their results.
- exposure A platform that issues API keys or opens accounts before ownership resolves to named humans is the party carrying whoever sits behind the wrapper.
- cost Every market whose registry will not answer an API call pushes onboarding into the document path, so each new jurisdiction buys OCR work on incorporation certificates and registers of members.
The state machine is where the bundle hurts. A KYC session has one subject and one verdict, taken at a single point in time [2]. A KYB record is a parent whose verdict depends on children that do not exist when onboarding starts. In the post's worked example, a company with two directors and two ultimate beneficial owners produces one entity-level KYB record and four linked KYC verification sessions the onboarding service has to coordinate [10]. Five rows for one signup [1], and four of them are created by traversal, after the first registry query comes back.
Traversal is the part your pipeline owns whichever SDK you bought. The post's diagram branches the root corporate entity into registry verification and entity graph traversal, labels the holding company node "(Recursively Resolve)", and hangs a KYC trigger off both the natural person owner and the director or signatory [19]. Depth is set by the applicant's structure, not by your schema: the traversal is described as running through parent companies, shell entities, nominee shareholders and trusts to reach the natural persons behind them [7].
Failure propagates upward. If any individual check fails an AML or sanctions review, the composite KYB state transitions to BLOCKED [11], so in that example the entity status is computed from four child outcomes [2]. Both corporate and individual nodes get screened, with the entity's canonical name, trading aliases and registered addresses going against OFAC, EU and UN sanctions data, regulatory enforcement watchlists and adverse media databases [8][15].
For stage one to transfer to your jurisdictions, the registry has to answer. The post has it querying SEC EDGAR, Companies House or state-level business databases through official open APIs or structured data brokers, and extracting canonical legal name, registration number or LEI, incorporation date, filing history and active operational status [13]. Stage two exists for when that is insufficient. It ingests certificates of incorporation, memoranda of association and registers of members, then runs OCR and entity extraction to recover share distributions and authorized signatories [14].
A legal entity cannot submit a biometric liveness check or hold an identity card up to an OCR model [4]. That constraint is why the output of a KYB check is a list of humans, and why the post says KYB does not replace KYC but triggers downstream KYC workflows [9]. Buy the bundle and you still store the join between one entity and N persons, plus the rule that folds four verdicts into one status. The teardown is a single dev.to post, with no timings and no named vendor product.
What to watch
- Whether the post's fifth pipeline component, absent from the published text, turns out to be ongoing monitoring, audit logging or something else.
- Which jurisdictions expose beneficial ownership through an open API, and which leave the OCR path as the only route.
- Vendor SDKs that expose the entity-to-person join and re-screening hooks instead of a single verdict field.