Identity Verification and E-Signature

Somebody has asked you whether BigLedger can check a customer’s identity before you sign them up, sign a contract electronically, or run a credit check before you extend terms — and you want a straight answer before you promise anything. This page gives it. The short version: the backend holds two identity verification (eKYC) integrations and one electronic-signature integration; exactly one of the three has a screen, on a sales contract; none of them does a credit check; and as at September 2026 no tenant has any of them switched on. Reading it takes about ten minutes, and there is nothing to configure, because nothing here can be configured from an applet.

Meet GadgetSphere

GadgetSphere Distribution Sdn Bhd (company GSD) supplies ultraportable laptops to corporate clients on 24-month subscription contracts. Each contract is a folder in the Sales Contract applet: the client’s signatory, the agreement they sign, and the recurring invoices the folder bills through. The finance clerk raising the folder has two reasonable wishes — to know that the person signing is who they claim to be, and to have the agreement signed without printing it — and this page is what the product can and cannot do about each.

The short answer, with the numbers behind it

BigLedger’s schema has a family of 21 tables prefixed bl_tpy_ — third party — for three vendors. The prefix is the only thing they share with the rest of the product: nothing in the sales, purchasing, inventory or e-invoice flow calls them, no background job reads their queues, and each is reached only through its own REST routes.

The zeros are measured, not assumed: an aggregate count over all 21 tables in every one of the 90 tenant databases and in the platform database on 2026-09-16 found no row anywhere, and the platform’s credential registry holds no entry of any of the three vendor types, in the platform database or in any tenant. The code was written between September 2022 and April 2023 and has not changed since. What this page describes is what is built, and it is honest about the difference between built and running.

A note on the CTOS name, because it is the one most likely to be misread: CTOS is a credit-reporting agency, but the integration BigLedger holds is CTOS’s eKYC product only. There is no credit report, CCRIS check or credit-score call anywhere in the backend. If somebody tells you BigLedger runs a CTOS credit check before a sale, the code does not support that.

Identity verification on a sales contract — the one screen

Open a sales contract folder and the second tab is EKYC. It shows a read-only EKYC Status and two sub-tabs, Profile Photo and Identification, each with a file upload. Once both hold a file, a VERIFY USER button appears. That button is the whole customer-facing surface of all three integrations.

What happens behind the scene when you press VERIFY USER

The applet builds one request carrying the profile photo, the identity-document image(s) and a small header record: a fresh identifier and the customer of the contract (the folder’s entity). The backend first asks Innov8tif for a journey id using the tenant’s stored username and password, then sends both images to the vendor’s OKAY Face service. The vendor returns a liveness probability, score and quality for the selfie and a confidence that the document is a genuine identity card.

Two thresholds decide the outcome, and both are fixed in code: liveness probability at or above 0.7 and identity-card confidence at or above 0.7. When both pass, the verification header is marked OKAY_FACE_VERIFIED. When either fails, the header is saved with no status at all — the call did not fail, the person did. Either way the vendor’s four numbers are stored on a verification-detail row, and both images are kept as attachments in the tenant’s file store against the header, so the evidence survives the toast.

EKYC Status on the Main Details tab is not a field you fill. When the folder opens, the applet looks up the most recent verification header for the folder’s customer and shows its status. Verify the same customer on a second contract and the first folder shows the newer result, because the status belongs to the person, not the contract.

Who may press it

The face call needs the permission TNT_API_INNOVATIF_CREATE_OKAY_LIVE, or a tenant owner, tenant admin or platform admin. Reading and writing the verification header needs the TNT_API_INNOVATIF_EKYC_HEADER_* family. These sit in the platform’s third-party permission set, not in the Sales Contract applet’s own permission list, so a user who can edit contracts is not thereby able to verify one.

The EKYC Required flag does nothing yet

A sales contract template carries EKYC Required and EKYC Validity Period (in months), and a folder copies the flag. Both are saved and can be filtered on; nothing reads them. The EKYC tab appears on every folder whether or not the template requires it, a folder with an unverified customer saves and bills exactly like a verified one, and no job or validator compares a verification date with a validity period. Treat the checkbox as a note to yourself, not as a control — and if you were counting on it to stop an unverified contract, that guard has to be a person for now.

The second identity vendor, which no screen reaches

The CTOS integration works differently: BigLedger does not send images. It creates a transaction at CTOS with the document name, number and type to be verified, a URL the person should be returned to and an optional callback URL, and receives an onboarding id, a hosted onboarding URL and an expiry time. The person completes the journey on CTOS’s own pages. Afterwards a status request brings back where the journey got to — URL Not Opened, Processing, Completed or Expired — the overall result — Approved, Rejected or Not Available — and the four steps behind it: document capture with text similarity and landmark checks, a face-match percentage, a record match, and a knowledge-based authentication score.

Three things about it a reader should know. It runs against the platform database, not the tenant’s, so its credential is a platform-level registration and its records are not in your tenant. Its routes are mounted under …/tpy/innovatif-ekyc/…, the other vendor’s name, and its database constraints are named for Innov8tif too — it was cloned from the Innov8tif integration and the labels were never changed, so an integrator reading the route table will find CTOS under the wrong heading. And it is reachable only by calling those routes directly: no applet, no processor.

Electronic signature — built, with no screen

The SigningCloud integration is the most complete of the three, and the one with the least surface. In the backend a signing run is: register the account (the vendor reports how many digital signatures, SMS credits and how much storage remain, and the maximum signers per document); add the signers (name, e-mail, phone, role); create a document and upload the PDF with a sign set per signer — page index, position from the left and top, and the size of the signature box; then either auto-sign (the company signs server-side with an uploaded signature, seal or company image) or manual-sign (the signer receives an authentication code and signs at a URL the vendor issues). The document’s sign_state moves from NOT SIGNED to COMPLETED or REJECTED; verify, download, list and delete exist, and every step lands in an audit log.

What it would sign is the interesting part. The signing document header carries the same numbering fields as every BigLedger financial document — server_doc_*, client_doc_* and their types — and its queue table insists that the row point at a real document header and line. The design anchors an e-signature to a BigLedger document. Nothing populates that anchor. No sales invoice, sales contract agreement or any other document creates a signing document, and the Sales Contract applet’s own Signature required flag on an agreement template is written but never read. The agreement a GadgetSphere client signs today is a mail-merge document signed outside BigLedger.

One feature or three?

The link table between a signer and a verified identity says the three were meant to work together: verify who the signer is, then let them sign. The scenario it was built for is GadgetSphere’s: a customer who is about to sign a two-year commitment proves who they are first, and the signature then carries that proof. When a signer is linked to an identity record, the backend copies the identity’s result onto the signer as ekyc_verified, and only an Approved result qualifies.

But the identity it reads is the CTOS one. The table is named for Innov8tif, its foreign key points at the CTOS header, and the service reads the CTOS verification_result. The only screen that verifies anybody uses Innov8tif, whose result lives in a different table the link never looks at. So the intended flow — verify on the sales contract, then sign the agreement — cannot be completed even in principle with what is built: the screen verifies with one vendor and the signing link checks the other. It is one design, delivered as three unconnected pieces.

What it will not do

• No credit check. The CTOS integration is eKYC only. Nothing calls a credit report, CCRIS or a score, and nothing feeds a customer’s credit limit or blacklist from any of these tables.
• No enforcement. EKYC Required and the validity period are stored and never read; an unverified customer’s contract saves, bills and posts like any other.
• No expiry. Nothing re-checks a verification after the validity period, or at all.
• No e-signature screen. SigningCloud is reachable by REST only; no applet lists, uploads or signs a document, and no document flow creates one.
• No automatic path. None of the three has a job processor; the open-queue tables exist and nothing reads them. Nothing runs later.
• No self-service switch-on. Each vendor’s credential is a row in the platform’s resource registry (the same registry that holds database connections), registered by BigLedger; there is no setting for any of them in the Sales Contract applet or the tenant admin.
• No identity verification anywhere else. Not at the till, not on the customer record, not on customer onboarding, not on e-invoice buyer identity — the EKYC tab of a sales contract folder is the only place.

What goes wrong, what you see, and what to do

How you know it worked

For a single verification: reopen the folder — EKYC Status reads OKAY_FACE_VERIFIED. That field is loaded from the verification header on open, so a status you see is a status that was stored.

For whether the integration is switched on at all: the thirty-second test is to press VERIFY USER once with any two images. A vendor answer of any kind, including a rejection, means the credential exists; the REQUIRED RESOURCE error means it does not. As at September 2026 the second is the answer on every tenant.

How this relates to the rest of the product

• What must exist before it works. A customer — every verification is filed against the contract’s entity, so a folder with no customer cannot be verified; a sales contract folder to hold the tab; and a vendor credential in the platform registry, which is the piece missing everywhere.
• What becomes possible because it exists. A stored, evidenced identity check — images and the vendor’s scores — against the person on a subscription contract, which is exactly what a device financing or rental business is asked for when a contract is disputed. The signing integration, once given a screen and an anchor, would let that same person sign the agreement without leaving the folder.
• Its sibling, and when to use which. Identity verification answers who is this person. The controls the sales flow already reads answer a different question — should we sell to them: the credit limit filter shows available credit and the blacklist rejects the document. Use those for terms; use eKYC, when it is on, for the person signing.
• What breaks if it is wrong. Today, nothing downstream: no posting, stock, e-invoice or membership step reads a verification result, so a wrong or missing status affects only the folder it is shown on. That is the consequence of no enforcement — harmless and useless in equal measure.
• What it pairs with in practice. The folder’s recurring sales invoices: the contract is verified once and billed monthly, so the identity check is a one-time gate on a long relationship rather than a per-sale step — which is why it lives on the contract and not at the till.

Where to go next

• Sales Contract applet — the folder, the template and the EKYC tab this page explains.
• Sales module — the credit limit and blacklist, which are the controls that do act on a sale.
• Integrations API reference — the generated route table where the CTOS, Innov8tif and SigningCloud controllers are listed, with the naming caveat above.