Piliin ang iyong wika
E-signature
Ang halaga ng isang lagda ay nakabatay sa pagkakakilanlan sa likod nito. Kinukumpirma ng signer identity verification API ng ShieldID na isang tunay na tao, hawak ang sarili niyang government ID, ang kumukumpleto ng iyong dokumento — kasama ang check na nakatala sa record katabi ng mismong lagda.
Ang problema
Karamihan sa mga e-signature platform ay kinukumpirma lang na may nagbukas ng email at nag-type ng pangalan. Authentication iyon ng inbox, hindi identification ng isang tao.
Sinumang makakabukas ng email — shared inbox, na-forward na mensahe, nakompromisong account — ay maaaring mag-click at mag-type ng pangalan sa signature box.
Ang isang lease, loan agreement, settlement o power of attorney ay may tunay na kahihinatnan. Ang "Sang-ayon ako" na tinype ng hindi na-verify na partido ay mahinang pundasyon para sa isang bagay na napakahalaga.
Kung sabihin ng isang signer sa kalaunan na ibang tao ang pumirma para sa kanya, karamihan sa mga audit trail ng e-signature ay nagpapakita ng IP address at timestamp — hindi ng government ID na na-check laban sa live na mukha.
Isang halimbawang senaryo
Kathang-isip, para ipakita ang hugis ng flow. Walang tunay na tenant, landlord o lease na kasangkot.
Ang pinakamahalaga bago ang isang lagda
Tumatakbo ang bawat check sa ibaba sa bawat verification, anuman ang dokumento.
Para sa mga hindi pagkakaunawaan at audit
Kinukuwestiyon ng isang signer sa kalaunan ang isang dokumento. Humihingi ang isang litigator ng ebidensya kung sino talaga ang pumirma. Sinusuri ng isang regulator ang iyong client-identification file. Ang identity check sa likod ng lagda ang panimulang punto ng usapang iyon.
Maaaring magdagdag ng mga entry. Hindi maaaring i-edit o burahin ang mga ito — hindi ninyo, hindi rin ng ShieldID. Katangian iyon ng mismong database.
Itinatala ng ledger ng ShieldID ang verification na naganap bago pumirma — sino ang sinuri, ano ang iniulat ng engine, kailan — bilang sarili nitong entry, hiwalay sa sariling record ng iyong e-signature platform ng pag-click.
Kunin nang eksakto ang mga entry na kailangan ng isang dispute o file review sa halip na manu-manong buuin ang timeline mula sa dalawang magkaibang system.
Sa ngayon, itinatala ng ledger ang mga resulta ng verified at failed na verification, sign-in at aktibidad ng API-key, at audit export. Malapit nang dumating ang per-view at per-download events para sa mga ID image, isang dedikadong decision event, purge receipts at self-service CSV export para sa iyong team.
Mga opsyon sa integration
Gumagana na sa production
Ang signer identity verification ng ShieldID ang nagpapagana sa Trust Ledger, ang sariling e-signature product ng Crown Stack Systems — ang parehong document checks, face match, liveness at Activity Ledger na inilalarawan sa pahinang ito, tumatakbo na sa mga tunay na signing flow ngayon, hindi lang bilang plano.
Mga tala sa privacy
Ang dokumentong sulit lagdaan ay madalas na sulit ding protektahan nang kasing-ingat ang pagkakakilanlan sa likod nito.
Kumpara sa manu-manong paraan
Paghahambing ng kategorya, hindi pahayag tungkol sa anumang partikular na vendor.
| Kakayahan | ShieldID | Karaniwang enterprise IDV | Mga manual na check |
|---|---|---|---|
| Kinukumpirma ang totoong tao, hindi lang ang inbox | Oo | Karaniwan | Hindi |
| Liveness challenge, hindi static na larawan o checkbox | Oo | Karaniwan | Hindi |
| Binabasa at kini-cross-check ang government ID | Oo | Karaniwan | Hindi |
| Inilalagay ang identity check sa isang mahahanap na talaan | Oo | Hindi inaalok sa customer | IP address at timestamp lamang |
| Nakakabit sa partikular na dokumento o envelope | Oo | Karaniwan | n/a |
| Sandbox na hindi kailanman sinisingil | Oo | Minsan | n/a |
Mga pagtutol
"Hindi ba nagve-verify na ng pagkakakilanlan ang aming e-signature tool?"
Karamihan ay umaasa sa email link, SMS code o nai-type na pangalan — patunay na may kontrol ang isang tao sa inbox o numero ng telepono, hindi patunay kung sino talaga siya. Nagdaragdag ang ShieldID ng aktuwal na government-ID at live-face check.
"Hindi ba babagal ang pagpirma dahil sa dagdag na hakbang?"
Isa itong hosted na hakbang, sa sariling telepono ng pumipirma, na inilalagay nang isang beses bago ang signing screen. Patakaran ng inyong platform kung gaano kadalas itong uulitin para sa bumabalik na pumipirma, hindi ito ipinipilit ng ShieldID sa bawat dokumento.
"Legal bang kinakailangan ang pagpirma na may kasamang ID?"
Depende iyon sa inyong hurisdiksyon, uri ng dokumento at payo ng inyong abogado — hindi kami nagbibigay ng legal advice. Ang idinaragdag ng ShieldID ay mas matibay na ebidensya kung sino ang nasa kabilang dulo ng pirma, na kapaki-pakinabang kahit ito ay hindi sapilitan.
"Maaari ba naming gamitin ito para lamang sa mga dokumentong mas mataas ang halaga?"
Oo — tawagin ang ShieldID para sa mga dokumentong nangangailangan nito at laktawan para sa mga hindi. Hakbang itong idinaragdag mo sa isang partikular na signing flow, hindi all-or-nothing na switch para sa buong platform ninyo.
Ang makikita mo
Pinapatunayan ng mga pumipirma kung sino sila bago pumirma. Ang resulta ay nakalakip sa envelope: bawat field na nabasa mula sa ID at bawat check nang hiwalay.
Mga Tanong
Magsimula
Gumawa ng sandbox session, magsagawa ng verification gamit ang sarili mong telepono, at tingnan ang record na isinusulat nito bago pa may tunay na signer na humawak nito.
Hindi kailanman sinisingil ang mga sandbox session.