Technical · For the entitlement and platform team
One entitlement path. Done well.
You pick the path. For 90 days, every decision on it gets a signed receipt that ICE and the customer both hold. When that works, we move to the next one. Everything below builds from your scope: the event, the calls, and a set of signed example receipts you can check yourself.
Self-guided tour · Eleven stops · About fifteen minutes
Why this exists, then how it works.
Agents now ask for licensed data for named users
On July 29, ICE made its fixed income data available to licensed users over AI platforms, with user permissioning built in. Every one of those requests is an entitlement decision.
Both sides need the same record
When a customer questions a bill, a denial or what an agent pulled, each side checks its own logs today. A receipt both sides hold settles whose record is right.
Start small on purpose
One path for 90 days, with four pass or fail measures. If it works, you pick the next path. Nothing else changes in the meantime.
- 1Scope one path
- 2The event
- 3Signed receipts
- 4Check them
- 5The calls
- 6The API shape
- 7Where it plugs in
- 8Security
- 9The answer record
- 10The whole package
- 11The 90-day test
Built on how ICE already works
Five things from ICE's own documents, and what each one means for the receipt
ICE's MCP connector runs at fids-mcp.ice.com/mcp with OAuth sign-in. The public connector directory lists six tools, each with read permission: ids_query_trades, ids_get_reference_data, ids_describe_concept, ids_get_schema, ids_classify_trade_size, ids_compute.
channel, tool and platform record exactly which door and tool each request used.
ICE says users should “pay for the value of the data delivered, rather than the volume of compute consumed.” A request across about 3,300 bonds returns one result, “quoted before the query runs and aggregated across every user at the firm.”
quote ties the quote, the acceptance and the delivery together, so the firm-wide total can be rebuilt from receipts both sides hold.
ICE's Data Services Agreement, section 10, asks the subscriber to keep “complete and accurate records” of access and usage for the most recent 36 months. ICE can audit for 24 months after the term, and an underpayment of 5% or more shifts audit costs to the customer.
The customer's copy is that record. Both sides hold the same one, so an audit starts from agreement on the facts.
The same agreement defines Authorized Users as “employees or third party agents” of the subscriber, and the subscriber is bound by any action taken with its credentials, whether it authorized it or not.
requester and on_behalf_of show which agent acted for which user, so “we didn't authorize that” has an answer.
ICE's market data policies count display use per active user and non-display use per device.
An agent answering a user blurs that line. The optional use field lets counts follow whichever rule ICE applies, without changing the event.
For Friday
Three decisions, and this page writes the rest
- Which path. Pick it in step 1. Default is evaluated pricing over the MCP connector.
- How events get to Hive. Pattern A, B or C in step 7.
- Who owns it. One test customer and one named owner on each side.
Download scope.json at the end of step 1 and it's the Day 1 checklist.
Open questions for your team
- Does the quote ID exist today as an event we can read, or only inside billing?
- For an agent answering a user in an AI assistant, is that display or non-display use?
- Where does the MCP permission decision get logged today: the gateway, the entitlement engine, or both?
Step 1 · Scope it
Pick one entitlement path. Everything else on this page builds from it.
Each choice on the left rewrites the plain-English summary and scope.json on the right. The event, the curl calls and the checks further down are all built from these same choices. Download scope.json and it becomes the Day 1 checklist.
Entitlement projects tend to stall when they try to cover every product at once. One path gives your team a result it can measure in 90 days, a small security review, and a job for one engineer. Every choice has a sensible default, so nothing waits on a meeting.
Step 2 · Run it
The event your team sends, and the receipts that come back.
The event on the left is built from your scope. Edit anything and check it here, in your browser. On the right are six real signed receipts from an example day. The receipt endpoint opens for the test, not before.
Press "Check this event".
This is the one message your system sends per decision. “Check this event” runs the same rules the test endpoint will use: required fields, types, and the agent job check. Try “Make it go off task” to see a flag, or add a field called payload to see it refused.
The event is a short list of facts your entitlement system already knows: who asked, for whom, what, under which license version, and the answer. Hive never needs the data itself. That keeps this outside your data licensing terms and keeps the security review about a feed of IDs.
An allowed person, an allowed agent, a denial, a license change at 17:00, an agent off task, and a skipped sequence number. Signed with a Hive-held demo key. Customer is fictional.
Each event became a receipt: the event, its fingerprint, the checks, the verdict, a link to the receipt before it, and a signature. The summary counts allowed, denied and flagged decisions, and notices that decision 1006 never arrived.
A log is only as good as whoever runs it, and a customer can't check yours. Your agreement already asks customers to keep 36 months of access records. This gives them a copy that matches yours. A signed, chained receipt can be checked by either side without access to the other's systems. If one is edited, removed or put out of order, the check fails.
Step 3 · Check it
Anyone holding a copy can check it. Change one character and it fails.
This check runs in your browser with the pinned public key. It doesn't call Hive.
Results appear here.
Your browser recomputes every fingerprint and checks every signature against the published public key. The second button changes one word in one receipt and checks again.
Nobody has to trust Hive, or ICE, to know a receipt is intact. The usual alternatives, audit letters and controls reports, come once a year and look at samples. This checks every decision, whenever anyone wants.
node verify.mjs receipts.json OK evt-1001 allowed OK evt-1002 allowed OK evt-1003 denied OK evt-1004 allowed OK evt-1005 allowed_flagged OK evt-1007 denied GAP missing seq 1006 All 6 receipts check out
Node 18 or later. No dependencies. It checks each event fingerprint, each receipt fingerprint, the Ed25519 signature against a pinned key, every chain link, and gaps in your sequence numbers. In the test, you pin ICE's own public key next to Hive's.
The same check as a small script. It needs Node and nothing else, and it prints one line per receipt plus any gaps.
Disputes show up months later, often with lawyers or auditors involved. The check has to work without Hive's servers, a login or a network. It still works if Hive isn't around at all.
From a terminal
The calls your team would make, as curl. Built from your scope.
These are the calls for the test endpoint, which opens on Day 1. The offline check in the Verify tab works today on the example receipts.
The same calls as plain HTTPS and JSON, filled in from your scope. They point at the test endpoint, which opens on Day 1 after your security review.
There's nothing to install in your stack: no SDK, no agent, no library. Any language that can send JSON can send events, which is why the setup estimate is one to two engineering days.
API reference · v0.1, proposed for the test
Four routes. One event shape.
| Route | What it does |
|---|---|
POST /api/ice/entitlements/receipt | One event, or {"events":[...]} up to 500. Optional prev_receipt_sha256 continues a chain from an earlier batch. Returns signed receipts and, for a batch, a summary with counts and sequence gaps. |
POST /api/ice/entitlements/verify | One receipt, or {"receipts":[...]} to check a chain. Same checks as verify.mjs. |
GET /api/ice/entitlements/key | Sandbox public key as a JWK, with its key ID. |
GET /api/ice/entitlements/schema | Event fields, required and optional. |
Opens for the test on Day 1. JSON in, JSON out. Body limit 512 KB. Access by mutual TLS or a key you issue, your choice. Your security review happens before it opens.
| Field | Type and example | Why | |
|---|---|---|---|
event_id | REQUIRED | string · "evt-1001" | Your decision or request ID |
occurred_at | REQUIRED | ISO 8601 · "2026-10-02T14:02:11Z" | ICE's clock, not Hive's |
customer | REQUIRED | string · "WF-0042" | Decides whose copy the receipt goes to |
requester | REQUIRED | {"type":"agent","id":"wf-agent-7"} | Tells a person from an agent |
on_behalf_of | AGENTS | string · "WF-U-88213" | The named user an agent acts for. An ID, no names |
dataset | REQUIRED | string · "ice_evaluated_pricing" | What was asked for |
license | REQUIRED | {"id":"WF-2291","version":4} | The version makes mid-day changes provable |
decision | REQUIRED | "allow" or "deny" | Denials get receipts too |
seq | OPTIONAL | integer · 1001 | Both sides can see a missing decision |
channel, tool | OPTIONAL | "mcp", "ids_compute" | Which door and which MCP tool the request came through |
platform | OPTIONAL | string · "claude", "ice_chat" | Which AI platform the agent was running in |
quote | OPTIONAL | {"quote_id","quoted_units","accepted"} | Ties the value-based quote to what was delivered. Units are ICE's own |
use | OPTIONAL | "display" or "non_display" | Lets counts follow your unit of count, per user or per device |
rule | OPTIONAL | string · "not_in_license" | The reason your system gave |
instrument_count | OPTIONAL | integer · 312 | Needed for the job check and for counts |
response_sha256 | OPTIONAL | 64 hex | Fingerprint of what was sent. Computed on ICE's side |
approved_job | OPTIONAL | {"job_id","max_instruments","window_utc","datasets"} | Turns on the agent job check |
ext | OPTIONAL | object | Anything else you want on the receipt |
Refused anywhere in an event: fields named payload, content, data, body, response, values, prices or records. The endpoint returns 422 with the field path. The event check in step 2 applies the same rules. Receipts carry fields and fingerprints only.
Four routes and one event shape. The required fields are the minimum that make a receipt useful in a dispute. Everything else is optional, and you can cross out what you don't need.
The license version lets both sides prove what the terms were at 16:59 and at 17:01. The on_behalf_of field ties every agent request to a named user, which is how access over AI platforms is permissioned. Denials are receipted too, because a disputed denial matters as much as a disputed delivery.
Verdicts
allowed, denied, allowed_flagged, denied_and_flagged. A flag means the job check found the request outside the approved job. It goes to the customer's data owner and ICE's entitlement owner. A person decides.
Canonical form
JSON with keys sorted at every level and no whitespace. SHA-256 over UTF-8 gives event_sha256 and receipt_sha256. Ed25519 signs the canonical receipt. Twelve lines of code in any language.
Chain and gaps
Each receipt carries the previous receipt's hash. Pull one out, reorder two, or edit any field and the chain breaks. Your seq numbers show a decision that never arrived.
400 invalid_json
404 not_found
405 method_not_allowed
413 too_large body over 512 KB, or more than 500 events
422 invalid_event {"errors":[{"field":"events[3].license","problem":"required {\"id\":\"...\",\"version\":N}"}]}
Receipts use SHA-256 and Ed25519, standard tools in every major language. When an agent strays outside its approved job, the receipt raises a flag and routes it to a named person on each side.
Blocking would put Hive inside your access path, adding delay and a new way for access to fail. Your entitlement system keeps enforcement and Hive keeps the record. There's also no blockchain here: no tokens, fees or public ledger. A signed chain gives the same tamper evidence and stays private.
Where it plugs in
Three ways in. Your team picks the one closest to what exists today.
A. Tap the decision stream
If allow and deny events already land on a topic or bus, a small consumer batches them and posts. Nothing in the access path changes.
for await (const batch of consumer.batches({ maxMs: 60000, max: 500 })) {
const events = batch.map(toHiveEvent);
const r = await fetch(HIVE + "/receipt", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ events, prev_receipt_sha256: head })
}).then(r => r.json());
head = r.summary.head_receipt_sha256;
await consumer.commit(batch);
}
B. Hook the MCP gateway
Right after the user permissioning check on each tool call, emit the decision to a local queue. The request never waits on Hive.
const decision = await entitlements.check(user, tool, args);
queue.push({
event_id: req.id, occurred_at: now(), seq: seq++,
customer: user.account,
requester: { type: "agent", id: client.id },
on_behalf_of: user.id, channel: "mcp", tool,
dataset: tool.dataset,
license: { id: lic.id, version: lic.version },
decision: decision.ok ? "allow" : "deny",
rule: decision.rule, instrument_count: args.ids.length
});
return decision; // unchanged
C. Daily file
If the easiest thing is an export, drop one JSON Lines file a day. Hive receipts it in order and returns the chain head for your records.
# entitlements-2026-10-02.jsonl
{"event_id":"evt-1001","occurred_at":"...","seq":1001,...}
{"event_id":"evt-1002","occurred_at":"...","seq":1002,...}
jq -s '{events: .}' entitlements-2026-10-02.jsonl \
| curl -s -X POST \
https://thehiveryiq.com/api/ice/entitlements/receipt \
-H 'content-type: application/json' -d @-
If Hive is down. Access works exactly as it does today. Events wait in your queue and backfill in order. The gap shows on both records, so nobody has to take our word for it.
Latency. None added. Every pattern above sits after the decision. The one optional line on the request path is the response fingerprint, a SHA-256 you compute locally.
Three ways to feed events, from lightest touch to most direct. All three run after the decision is made.
Your team picks what's closest to what already exists. With a decision stream, A is a small consumer. If the MCP gateway is where decisions happen, B is a few lines. If exports are easiest, C is one file a day. None of them changes how access works.
Security and data
What leaves ICE is a list of decisions. Never the data.
What's sent. IDs, codes, license versions, decisions, times, counts and fingerprints. No names, no prices, no positions, no content. The API refuses content-shaped fields.
Who holds keys. The example receipts are signed with a demo key Hive holds, and we say on every receipt that it is not independent. In the test, Hive signs as the third party with a production key that neither ICE nor the customer holds. ICE can add its own signature from its own key management, and the customer can countersign. Neither is needed to start, so nothing has to change in ICE's key systems on Day 1.
What Hive keeps. This page sends nothing to Hive. Every check runs in your browser. In the test, retention, region and deletion are yours to set on Day 1, and written into the test agreement.
Your review. Tell us what your security review needs and we'll answer it in writing before any feed is turned on. The scope is small: one outbound feed of fields.
The four questions a security reviewer usually asks first, answered up front.
The fastest review is a small one. Sending fingerprints instead of data keeps the scope to one outbound feed of fields, with keys, retention and region under your control.
Step 4 · The answer, not just the access
When an AI assistant answers with ICE data, the customer can show which numbers were ICE's.
The entitlement receipt says the request was allowed. This record covers what came back. Each sentence that states an ICE value is tied to the exact ICE value it rests on, with its evaluation time, method and reason code. Everything else is marked as the model's words. It matches ICE's own disclaimer, “The analysis and summary is generated by AI. The data is provided by ICE Data Services,” one sentence at a time.
Analyst asked
ICE states an ICE value, checkable. Model the model's own words. Click any sentence to see what it rests on.
Click a sentence.
Press "Check the answer".
Three records, all standard Hive receipt types: sigr.gca binds each sentence to its ICE value, assembly.receipt binds the prompt, ICE's response and the model's text into the one answer, and supersession.receipt links a correction without touching the original. The ICE response here is the same one entitlement receipt evt-1002 points to. Values are synthetic. Signed with the Hive demo key, which Hive runs and which is not independent. Hive's live canon verifier at thehiveryiq.com/v1/verify passes the schema, fingerprint and signature on all three, and reports the signer as unregistered, which is correct for a demo key.
Your browser recomputes every sentence fingerprint, every ICE value fingerprint, the claims root, the three-part assembly and both signatures. The buttons change one number, relabel one sentence, or show ICE's own correction, and the check says exactly what changed.
Funds put these answers in valuation files. SEC Rule 2a-5 and Rule 31a-4 expect records that support fair value, and ICE's July report already describes a PDF “for the analyst's audit file.” This makes that file checkable: ICE's numbers stay ICE's, a price challenge leaves a clean trail, and the model's words can't borrow ICE's name.
ICE monthly report, July 2026 · SEC Rule 2a-5 release · ICE Enhanced Evaluation Transparency
The whole package
Every step of an ICE request, and the receipt that covers it.
We went through all 135 entries in the Hive canon against ICE's agreement, its MCP connector and its evaluated pricing. 23 receipt types apply to ICE. Seven are in the 90-day test. The other 16 are built and running on Hive's receipt service today, so when your team asks “what about revocation, or the 36-month records, or billing,” the answer is already built. The rest of the canon is for other industries and isn't part of this.
Was this request in the license?Every allow and deny on the path, with the rule and license version.
Authorization Decision Receiptauthorization.decisionShown on this page in a readable ICE form.
In the test
Which agent acted for which user?The DSA counts third party agents as Authorized Users and binds the subscriber either way.
Delegated authority chainauthority.delegation
In the test
Did the agent stay inside the user's rights?An agent's scope can never be wider than the person it works for.
Delegation Attenuation Receiptdelegation.attenuation
In the test
Did the person granting access hold the license?For firm admins who set up agents for others.
Granter Qualification Receiptauthority.qualification
Ready next
Was ICE's notice shown?ICE's AI disclaimer or license terms, shown to this user at this moment.
Disclosure Presentation Receiptdisclosure.presentation
Ready next
Which numbers were ICE's?Each sentence tied to the ICE value it rests on. Model words marked as the model's.
SiGR GCA, grounding claimssigr.gcaBuilt on this page, step 4.
In the test
What went into the answer?The prompt, ICE's response and the model's text, bound into the one answer the customer holds.
Multi-provider assembly receiptassembly.receipt
In the test
Can ICE's compute be replayed?For ids_compute: the same inputs and method give the same output.
Analysis Replay Receiptanalysis.replay
Ready next
Does the customer's number match ICE's?When a filing or a risk system shows a value that differs from what ICE sent.
Multi Source Divergence Detectiondivergence.record
Ready next
Was the quote inside the user's limit?An agent accepted a 120-unit quote. Was that within what the user allowed?
Mandate Conformance Receiptmandate.conformance
Ready next
What's the firm-wide total?ICE aggregates quotes across every user at the firm.
Cumulative Mandate Receiptmandate.aggregate
Ready next
What did the month add up to?Units for a billing window, and how many of them are backed by a receipt.
Service Level Metering Receiptsls.metering
Ready next
ICE revised a price.After a price challenge, the corrected value links to the original, which stays checkable.
Correction and supersession receiptsupersession.receiptBuilt on this page, step 4.
In the test
The method or the model changed.A dated notice that the serving setup changed, before and after.
Model Change Notice Receiptmodel.change
Ready next
The license ended. Did access stop?Whether a request came inside or after the cutoff window.
Authority Revocation Receiptauthority.revocation
Ready next
Nothing went out after termination.No access on the named channels over a closed period.
Effect Quiescence Receipteffect.quiescence
Ready next
Both copies match.ICE's record and the customer's record, compared each day without sharing either.
Ledger Parity Receiptledger.parity
In the test
Order and time nobody can move.Event order fixed against an outside timestamp authority and a public block.
Sequence Attestationsequence.attestation
Ready next
The log wasn't rewritten.A checkpoint of the whole log, with proof that later logs extend it.
Transparency Checkpoint Receipttransparency.checkpoint
Ready next
No gap from request to filing.A continuous chain from the entitlement decision to the answer in the file.
Causal Path Receiptcausal.path
Ready next
36 months, on the record.The retention rule in DSA section 10, committed with a date.
Retention Policy Commitment Receiptretention.policy
Ready next
Records aged out on schedule.A deletion measured against the policy that was in force.
Retention Purge Receiptretention.purge
Ready next
ICE data handed to a third party.A fund administrator or auditor receives it, both sides sign, with the stated purpose.
Custody Handoff Receiptcustody.handoff
Ready next
Every receipt type above is live on Hive's receipt service at thehiveryiq.com/v1, and each one can be checked offline. Names and definitions are exactly as they appear in the Hive canon, which also says what each one does not prove. “Ready next” means built and running on Hive's receipt service. It still needs ICE's fields and a named owner before it's on for ICE.
One map of an ICE request from the entitlement check to the valuation file, with the receipt that covers each step. Seven are in the 90-day test. The rest are ready when you want them.
One thing, done well. The test proves the entitlement path and the answer on it. Everything else plugs into the same event feed, the same keys and the same checker, so each next step is a scope decision, not a new project.
The 90-day test*, in engineering terms
One path, measured four ways. If it passes, you pick the next path.
In the test: the entitlement receipt for every decision on the path, the answer record for every MCP answer on it, and the customer’s copy of both. Seven receipt types, one event feed, one checker.
Receipt count matches your own decision count for every day, allowed and denied. Every MCP answer on the path has an answer record. Gaps are named, not hidden.
Both sides run the same check and get the same chain head each day.
Your team edits, removes or reorders receipts, or changes a number in an answer, on purpose. The checker catches every one.
No change in access latency or entitlement behavior. Agent flags reach both named owners the same day.
- 1Day 1
Scope signed off. Fields agreed. Keys set up. Your team picks A, B or C.
- 2Weeks 1 to 2
Feed on in a test environment. Counts compared daily.
- 3Weeks 3 to 12
One customer on the path. Customer copy on. Friday report each week.
- 4Day 90
Results against the four measures. You decide on the next path.
* The 90-day test is offered for entitlements only, the first focus ICE named. Nothing has been agreed. What we're asking of your team: none if a daily decision export already exists, otherwise one engineer for one to two days to set up the feed, and one named owner on each side for agent flags.
Four measures, each pass or fail, checked against ICE's own counts every day of the test.
Success is measured, so nobody has to rely on opinion at Day 90. If the path passes, you pick the next one. If it doesn't, you'll know exactly where it fell short and why.
Straight talk
Hive does not decide, enforce or block entitlements. Your system does that, unchanged. Hive does not watch what customers do with data after delivery. Counts on receipts are evidence, not an agreed billing quantity until both sides say so. The demo signer is Hive's own key and is not independent. All customer names on these pages are fictional.