FIDNT for Platforms · v1

The legal rail under your product.

FIDNT is a sovereign identity protocol. When your platform integrates, you stop guessing whether you have permission to act on a user's data — you have a signed receipt that proves it. Compliance becomes a query, not a project.

Legal basis — identity & signing map to UNCITRAL MLIT (2022); AI-agent attribution to MLAC (2024). Aligned to the standards, operating under the statutes in force. See the alignment →

§ 1 · What you get

Five things your platform receives.

Every integration ships with these. They are not features — they are primitives the protocol returns.

1

Verified identity

Re-use the user's existing FIDNT identity. No KYC re-run. PhilSys, passkey, biometric — already done.

2

Consent receipt

ISO 27560 / DPA 2012 receipt — signed by the user, scoped to your purpose, time-stamped, exportable.

3

Mandate scope

What you may do is in writing, signed by the user's key. Out-of-scope = invalid. Civil Code 1868.

4

Revocation feed

Webhook fires the instant a user revokes. You stop processing within seconds — defensible by design.

5

Audit ledger

Append-only, SHA3-512 hash-chained, ML-DSA-65 (FIPS 204) signed record of every consent, mandate, action and revocation. Court-admissible. Export on demand.

§ 2 · The compliance shield

What changes the day you integrate.

Most platforms accumulate compliance debt every day they operate. FIDNT swaps the unprovable for the provable.

Without FIDNT Today

  • NPC investigation → "Show me your consent record" → scrambling to produce screenshots and email logs
  • Data subject deletion request → manual ops ticket, 14-day clock, partial completion, residual liability
  • Mandate audit → hope your terms-of-service was clear enough; pray for a sympathetic regulator
  • User dispute → your word against theirs; burden of proof on you under the Data Privacy Act
  • Class action / collective complaint → no per-user paper trail; you defend at the policy level
  • Engineering owns compliance forever → every feature ships with a privacy review

With FIDNT Day 1

  • NPC investigation → API call returns the signed receipt — your defense is a JSON object
  • Deletion request → mandate revoked → automated downstream propagation; receipt of completion
  • Mandate audit → instant export of every consent, scope, version, ML-DSA-65 (FIPS 204) signature — court-admissible
  • User dispute → ML-DSA-65 (FIPS 204) signature; the user signed with their own key
  • Collective complaint → produce ledger range; each user's record is independently verifiable
  • Compliance is the product → engineering ships features; FIDNT carries the rail
§ 3 · The Agency model

Clean books. No withholding. The user is the principal.

FIDNT operates as the user's agent under Civil Code 1868. Money does not flow through FIDNT — it flows directly between your platform and the user. FIDNT issues the proofs. We are not a payment processor, not a money-service business, not in any custody role.

The transaction shape

Platform pays the user directly via your own rail (bank, e-money, PSP) → FIDNT issues the signed mandate + receipt + ledger entry → FIDNT invoices its disclosed admin fee to your platform separately, as service revenue.

What you avoid

No employer-employee relationship. No payroll withholding obligation. No 2316/2307 for casual data licensing. No SEC exposure from token rewards. No BSP exposure from money pass-through (because there is no pass-through). Tax burden lives where it legally belongs — with the user.

Tax framing for PH residents: passive royalty income to the user, 20% final tax. Platform receives a clean payment receipt + invoice from FIDNT for its books. We are not a money service business; the BSP regulates entities that receive deposits, issue e-money, or operate payment systems — none of which describes a routing-instruction + receipt issuer.

§ 4 · API surface

12 endpoints. 4 pillars. No surprises.

The full surface is small on purpose. Every endpoint maps to one of the four pillars. Anything that isn't here, FIDNT does not do.

MethodPathPurposeStatus
POST/api/authIdentity assertion · session startlive
POST/api/mandateRequest a signed mandate (scope, expiry)live
POST/api/consentIssue a consent receipt to your platformlive
POST/api/licensingData licensing terms (scope · duration · price)beta
GET/api/portabilityUser-initiated data export (DPA Sec.18)live
POST/api/credit-disputeBSP-defined credit information disputebeta
POST/api/npc-enforcementNPC complaint envelope (DPA Sec.16)beta
POST/api/ppsrPersonal Property Security Registry filingv2
GET/api/earningsUser royalty receipts log + earned-but-not-yet-paid attestationlive
POST/api/accountingPer-period reconciliation exportbeta
POST/api/messagesSend signed, consent-scoped message · real-time messaging backend in developmentbeta
GET/api/ledgerReceipt log · hash-chained · per-user rangelive

AI Agency rail · 6 endpoints

The same agency framework, applied to AI agents acting on a human's behalf. Civil Code 1868 was written for principals authorizing agents — it applies whether the agent is a person, a company, or a model.

MethodPathPurposeStatus
POST/api/agent/registerAI agent registers · receives an agent DIDv1.1
POST/api/agent/mandateUser signs mandate granting agent authority + scopev1.1
GET/api/agent/verifyThird party verifies the agent's mandate is live + in-scopev1.1
POST/api/agent/actionAgent logs an action with mandate proof attachedv1.1
POST/api/agent/revokeUser revokes agent's authority · webhook firesv1.1
GET/api/agent/auditPer-user audit trail of every agent actionv1.1

The unsolved problem in 2026 AI agents: no consent-rail, no scoped mandate, no revocation feed, no audit trail when something goes wrong. FIDNT is the only protocol with these primitives baked in, under a working legal substrate (Civil Code 1868 + DPA 2012 + ISO 27560).

Signing is real ML-DSA-65 (NIST FIPS 204), wired end-to-end. It runs on sandbox keys today and switches to the production signing key once set — the honest dev framing. ML-KEM-768 (FIPS 203) handles key exchange; SHA3-512 handles hashing.

live = production · authenticated · beta = sandbox-only, schema may change · v2 = on roadmap, not yet shipped. See /status for the honest capability surface.

§ 5 · Integration shape

Drop-in. Three pieces.

Most integrations are a button on the client, a verify on the server, and a webhook for revocation. Total integration time for the basic shape: half a day.

1 · Client — request a mandate

Single button on your page. Opens the FIDNT consent flow; user signs with their key.

// Request a mandate from the user (browser)
const mandate = await fidnt.requestMandate({
  platform: 'acme.com',
  purpose: 'underwrite a credit application',
  scope:   ['identity:basic', 'finance:read'],
  expires: '2026-12-31',
});

2 · Server — verify before acting

Every server-side action checks the mandate is still valid and in-scope.

// Server verify (Node / Deno / any runtime)
const res = await fetch('https://api.fidnt.com/mandate/verify', {
  method: 'POST',
  headers: { 'Authorization': `Bearer ${API_KEY}` },
  body: JSON.stringify({ mandate_id, scope: 'finance:read' })
});
if (!res.ok) throw new Error('mandate invalid or out of scope');

3 · Webhook — listen for revocation

The instant a user revokes, your platform stops processing. The receipt of stop is your defense.

// POST https://your-platform.com/webhooks/fidnt
{
  "event":      "mandate.revoked",
  "mandate_id": "mnd_01HK...",
  "user_did":   "did:fidnt:...",
  "revoked_at": "2026-05-04T14:23:00Z",
  "receipt":    "rcp_..."
}

Full SDK reference, error codes, idempotency keys, and replay attack mitigations are in the developer docs (link from your sandbox dashboard once you have keys).

§ 6 · Certified Integrator program

Three tiers. Honest pricing. Public directory.

Sandbox

Free · self-serve
  • Full API surface against test data
  • Mock receipts & mandates
  • Up to 10,000 calls / day
  • No production user data
  • No certification badge
Get keys

Live · Certified

Agency model · disclosed admin fee
  • Production API · real users
  • Signed FIDNT covenant on file
  • Public directory listing (when ready)
  • Webhook for revocation events
  • Quarterly audit cooperation
Apply

Sovereign Partner

Bespoke · enterprise
  • Co-design of new endpoints
  • Dedicated audit liaison
  • Charter-level certification
  • Joint compliance posture (NPC, BSP)
  • Direct escalation channel
Talk to us
§ 7 · Who benefits

If your platform processes data about people, you have a FIDNT-shaped problem.

AI agent makers · the rail you don't have yet

The legal substrate every AI agent needs

OpenAI · Anthropic · Microsoft · Google all ship agents. None ship a real consent-rail. When the first agent drains a real account or doxes a real user, every maker will need a layer they can point to. FIDNT is that layer — built first, in the right jurisdiction, under the right charter.

Banks · BNPL

Underwriting without re-KYC

Pull verified identity + consented credit-data scope. Cuts onboarding from days to seconds. Mandate carries the legal weight.

HMOs · Hospitals

Patient-held consent

DPA + HIPAA-parity. Selective disclosure for diagnosis, coverage, claims. Audit rail for every record release.

SaaS · B2B

Enterprise-grade trust without enterprise sales cycles

Show buyers a signed covenant, not a security questionnaire. Win the procurement review by default.

Creator platforms

Fan-data compliance shield

Quest, point, and token economies routinely trample DPA. FIDNT receipts make every fan-data action defensible — without changing your token mechanics.

CPaaS · messaging

The TCPA / DPA-parity layer

Communications platforms move billions of messages and absorb the compliance risk on each one. FIDNT receipts close the legal exposure per send — no matter which transport rail carries it.

Government · public

Citizen-held entitlement

Benefit-pull with receipt. No double registration. PhilSys reuse, not copy. Audit rail for the COA.

§ 8 · Honest capability surface

What is live, what is beta, what is next.

We don't ship "magic." Every endpoint you saw in §4 has a status. We publish what works, what is rough, and what is on the roadmap — at /status.