Self-sovereign identity gives every person, organisation, asset and device a portable, verifiable identity that its owner controls. A trusted issuer signs a credential, the owner holds it, and any verifier can check it without calling the issuer. The owner decides what is shared, for what purpose and for how long, and every credential and delegation leaves an audit record.
Key Takeaways
- Self-sovereign identity moves control of identity data from the platform to the identity owner.
- Credentials are issued once, held by the owner and verified many times, which removes repeated KYC and supplier onboarding.
- The model covers organisations, assets and devices as well as people, so a whole value chain can be identified.
- Consent, purpose, role and revocation are recorded, so privacy and accountability hold at the same time.
- LOA (Loan Origination Assistant) runs borrower and co-lender identity on this layer, and the same verified identity carries across MARCO (Marketplace Ecosystem) buyers and sellers.
What Is Self-Sovereign Identity
Self-sovereign identity, often shortened to SSI, is a model of digital identity in which the owner of the identity holds the proof. A bank, a government registry or an industry body issues a signed credential. The owner keeps that credential in a digital wallet and presents it whenever a counterparty needs to check a fact.
Most business identity today works the other way round. Each platform keeps its own copy of a customer or supplier record, and the customer proves the same facts again every time a new relationship starts. Lending feels this most, which is why LOA is built on a shared identity layer.
Self-sovereign identity replaces those copies with verifiable credentials that travel with the owner, each carrying a signature that proves who issued it and that it is unaltered.
How Does Self-Sovereign Identity Work
Three roles make up the model: the issuer, the holder and the verifier. A shared registry, usually a permissioned blockchain, stores the public keys and revocation status that let the three trust each other without a central database of personal data.
- An issuer, such as a bank, a registrar or a certification body, verifies a fact about the holder and signs a credential that states it.
- The holder stores the credential in a wallet that the holder controls.
- A verifier asks for proof of a specific fact, for example that a supplier is registered for tax or that a buyer has passed KYC.
- The holder consents and presents only the facts requested. Selective disclosure means the rest of the credential stays private.
- The verifier checks the signature and the revocation status against the shared registry and accepts or rejects the proof.
- The presentation, the purpose and the consent are logged, so an auditor can later see who relied on which credential and why.
The issuer is absent from the verification step, which is what makes the identity portable. In LOA, the lender is the verifier: bureau pulls and KYC and AML checks are called inside the loan workflow and logged on the file.
Four Characteristics Of Self-Sovereign Identity
- The identity owner controls what is shared. Nothing leaves the wallet without consent, and consent can be withdrawn.
- Data access is bound to a purpose. A lender that receives an income proof for a loan decision cannot reuse it for marketing.
- Credentials are verifiable. Any party can confirm the issuer and the integrity of the credential mathematically.
- Permissions are bound to roles. A director, a finance clerk and an auditor of the same company see and sign different things.
Delegation follows from the fourth point: an organisation can let a named employee or agent act for it, within limits and for a fixed period, and revoke that right later. Co-lending on LOA depends on role-bound identity, because each lender joins the file with its own verified identity and its own credit policy.
Self-Sovereign Identity Vs Centralised And Federated Identity
| Question | Centralised Identity | Federated Identity | Self-Sovereign Identity |
|---|---|---|---|
| Who holds the data | Each platform keeps its own copy | One identity provider holds it | The identity owner holds the credentials |
| How far it travels | Inside one platform | Across services that trust the provider | Across any ecosystem that trusts the issuer |
| What is shared | The full record | A profile set by the provider | Only the facts requested, with consent |
| Onboarding effort | Repeated for every relationship | Reduced inside the federation | Verified once and reused |
| Audit trail | Separate logs per platform | Held by the provider | Consent, purpose and delegation on a shared record |
| Covers assets and devices | Rarely | Rarely | Yes, by design |
What Self-Sovereign Identity Looks Like In A Business Ecosystem
A supplier is verified once and reused across ecosystems. Registration, bank account and tax status are checked at the first onboarding, and every later buyer that trusts the issuer accepts the credential. On MARCO, the marketplace platform, buyers and sellers are verified in this way before they trade.
A buyer, a borrower or an investor completes KYC once and the credential travels. On Pazalabs, our partner platform for real-world assets, KYC, AML and accreditation are verified once at onboarding before an investor sees an opportunity.
An IoT device, a part, a parcel of land or a luxury item can hold an identity in the same way, which is the basis of genuine parts traceability. A farmer can hold credentials for land, produce and transaction history, which becomes a verifiable credit history and a practical route to rural financial inclusion.
Why Self-Sovereign Identity Matters For Fraud, Privacy And Compliance
Identity becomes a single source of truth across ecosystems, validated continuously at every step. Every signature, approval and asset transfer can be tied back to a verified party acting within a known role.
That removes impersonation and fraud while keeping accountability. A forged invoice or a fake distributor is hard to sustain when every participant must present a credential that a trusted issuer stands behind. In LOA, every decision on a loan file is logged against the party that made it, so the audit trail shows who approved what.
Privacy improves at the same time. Personal data stays with the owner and is disclosed fact by fact, which fits data protection rules on consent, purpose limitation and erasure far better than copying full records between systems.
How LOA And The Istakapaza Platform Handle Self-Sovereign Identity
Self-sovereign identity is one of the three shared layers in the Istakapaza seven-layer ecosystem operating system, described on the platform architecture page. Every product uses the same identity, so the requirements of the model are met once and inherited everywhere.
- Verified parties. Personas are country-specific and include identity and bank validations. LOA calls KYC providers and bureaus inside the workflow and logs the result on the file.
- Reuse across products. A KYC credential cleared for one product can be reused in another, so a party verified in LOA or MARCO is recognised elsewhere on the platform.
- Consent, delegation and revocation. The identity layer is portable and verifiable, with consent, delegation and revocation built in.
- Privacy and erasure. Personal data stays off chain and only the proof is anchored on Hyperledger Fabric. Retention is configurable and the right to erasure is supported by jurisdiction, as set out on the governance and security page.
- Rules by role. Every approved event maps to an identity, a workflow and a ledger state, which lets a smart contract policy engine enforce credit limits and pricing by role.
See LOA Verify Identity On Your Own Loan Files
- Book a LOA identity and onboarding demo with the Istakapaza team.
- Bring a sample loan package and a note of the KYC, bureau and bank checks your team runs today, plus any co-lending or investor onboarding journey you want to compare.
- The session shows that package in LOA with each party verified and logged on the file, and how the same credential is recognised in MARCO without repeating the checks.
Read more about LOA, loan origination with document intelligence.
Frequently Asked Questions
What is self-sovereign identity in simple terms?
Self-sovereign identity is a way of proving facts about yourself, your company or your asset using digitally signed credentials that you hold yourself. A trusted issuer signs the credential once. You then present it to anyone who needs proof, and they can verify it without contacting the issuer or storing a copy of your full record.
Is self-sovereign identity the same as blockchain identity?
The two are related but different. Self-sovereign identity is the model of issuer, holder and verifier. A blockchain is often used as the shared registry for issuer keys and revocation status. In a well-designed system, personal data stays off chain with only a proof anchored.
How does self-sovereign identity support reusable KYC?
Once a regulated party completes KYC on a customer, it can issue a credential stating the result. The customer presents that credential to the next institution, which verifies the signature and revocation status. The second institution still decides whether to rely on it, but the documents are not collected and checked again from the start.
What happens when a credential is no longer valid?
The issuer revokes it. Revocation status is published to the shared registry, so the next verifier that checks the credential sees that it has been withdrawn. Delegations are revoked the same way when an employee leaves or a mandate ends.
Which lending software uses self-sovereign identity?
LOA, the Istakapaza Loan Origination Assistant, runs on the platform identity layer. Borrowers and co-lenders join the file with verified identities, KYC and bureau checks are logged on the file, and a KYC credential cleared in one Istakapaza product can be reused in another, including MARCO.
Glossary
- Verifiable Credential
- A digitally signed statement about a holder that any party can check for authenticity and integrity.
- Issuer
- The trusted party that verifies a fact and signs the credential that states it.
- Holder
- The person, organisation, asset or device that keeps a credential and decides when to present it.
- Verifier
- The party that requests proof of a fact and checks the credential against the shared registry.
Back to the blog.
