When an agent pays, books, or files on behalf of a subscriber or a company, the receiving side needs more than a software identifier. It needs to know who carries responsibility for the action. IDN is the accountability layer where that assurance is issued and verified, rooted in the verified subscriber relationships mobile operators already hold.
When an agent acts across an organizational boundary with financial, legal, or physical consequence, the receiving side is not asking which program sent the request. It is asking three questions about the party that will answer if the action was wrong.
Email addresses, payment cards, web domains, OAuth tokens and wallet signatures are all self-declared or self-custodied. They identify a sender. None of them binds an accountable party to the action, and that is the gap deepfake fraud, agent impersonation, and name squatting all walk through.
The receiving institution has a sender identifier and nothing standing behind it. FATF Travel Rule obligations and its own risk policy both require a named accountable party, which today means a bilateral integration with every counterparty it might ever meet.
The endpoint sits at a reachable address on the public internet, so anything that can find it can attempt to talk to it. Filtering hostile traffic falls entirely on the endpoint, which is the weakest place in the chain to do it.
A convincing name, a convincing voice, and a valid certificate are all cheap to obtain. Nothing in the request ties that name to a party a regulated issuer has verified and still stands behind.
The receiving system has to establish that the agent was authorized by the employee, that the employee was authorized by the company, and that the record of both survives across vendors long enough to be audited.
Add yourself to the reservation list. We'll confirm your handle availability and give you first claim ahead of public registration.