Fraud Models for Illiquid Assets: Detecting Identity Abuse in Private-Asset Marketplaces

Illiquid asset markets are structurally different from public exchanges. Private deals, capital calls, secondary transfers, escrow closings, and OTC transactions often produce sparse transaction histories, fragmented identity records, and delayed feedback loops. That combination creates a perfect environment for identity abuse: synthetic identities, account takeover, impersonation, mule payments, collusive buyer-seller rings, and document fraud can move through the workflow long before a rule-based system recognizes the pattern. For teams building controls in private marketplaces, the core challenge is not just blocking obvious bad actors; it is building a detection stack that can make good decisions when data is incomplete, stale, or intentionally obscured. If you are designing that stack, it helps to think of the problem the way we think about regulated onboarding in automated KYC for small brokerages: the workflow must be fast enough for real buyers, but strict enough to stop identity manipulation before funds and assets change hands.

This guide is for fraud, risk, ML, compliance, and platform engineering teams that need an enterprise-grade approach to fraud detection in private marketplaces. We will break down how to combine graph analytics, entity resolution, heuristic controls, and human-in-loop review into a layered model that works even when transaction volume is low and labels are sparse. We will also show how to explain model decisions to compliance and operations teams without reducing the system to a black box, borrowing lessons from trust-but-verify metadata workflows and from verification tooling used in adversarial monitoring environments.

1. Why Illiquid Asset Fraud Is Different

Sparse data changes the problem geometry

In a liquid payments or card environment, a fraud model may see thousands of transactions per account and enough chargebacks to learn stable patterns. In illiquid assets, the distribution is the opposite: a user may only transact once every few months, maybe once a year, and the “event” itself can include multiple sub-steps such as KYC, funding, title transfer, escrow release, and settlement. That means classic behavioral features like frequency, velocity, and short-term spend are weak or absent. The result is a domain where sparse data does not merely reduce accuracy; it changes what “normal” even means.

The fraud surface also expands beyond payments. A private-market buyer may use a legitimate bank account but a compromised corporate identity, or submit forged beneficial ownership documents through an otherwise valid portal session. Attackers know that illiquid markets rely on trust-heavy workflows and manual exception handling, so they target the weakest handoff point. This is why fraud controls should be designed alongside document processing, approvals, and transfer workflows, much like an enterprise building robust sign-off paths in multi-team document approval systems or maintaining change control in document automation templates.

Identity abuse is usually multi-stage

Most identity abuse in private markets is not one event; it is a sequence. A bad actor first establishes credibility with a thin but consistent identity, then gradually adds linked accounts, payment methods, and counterparties. In OTC deals, they may exploit loose controls around off-platform communication, introducing new bank details or a “replacement signer” shortly before closing. Because the underlying asset is illiquid, the feedback loop is slow: by the time losses surface, the transaction may already be settled and the counterparty gone. A detection strategy has to look for this sequence across channels, not only within a single login or payment event.

The same pattern appears in other high-trust, high-friction workflows. For example, teams that run sensitive document exchange in distributed operations often need a structured approval model to prevent one compromised step from becoming an organizational failure. The operational lesson is the same: if the business process has multiple handoffs, the fraud model must observe those handoffs as a chain, not as isolated records. That is why private-marketplace teams benefit from the same disciplined thinking used in regulated CI/CD systems: controls should be tested, versioned, and auditable.

OTC and off-chain records create blind spots

Private-asset ecosystems often split across portals, email, bank wires, custodians, cap-table tools, escrow agents, and legal documentation. Each system may have a different identifier for the same person or organization. If your model cannot reconcile those identities, you will miss both fraud rings and legitimate edge cases. That is where entity resolution becomes foundational: matching the same real-world entity across off-chain records, alias names, bank routing details, device fingerprints, beneficial owner records, and sanction-screening outputs. Without it, a fraudster can simply rotate one attribute at a time and remain invisible.

For organizations managing broader digital asset and custody workflows, this multi-system problem is familiar. The practical lesson from developer-focused integration marketplaces is that interoperability is not a nice-to-have; it is the control plane. In fraud detection, the same principle applies: you need reliable connectors, normalized schemas, and deduplication logic before ML can produce useful output.

2. Threat Model: The Main Fraud Patterns You Need to Detect

Synthetic identity and split identity

Synthetic identity fraud occurs when a bad actor combines real and fabricated elements to create a profile that passes shallow checks. In illiquid asset marketplaces, the profile may look clean because there are few previous transactions to contradict it. Split identity is a related pattern in which one actor operates multiple personas across entities, portfolios, or SPVs. Both are hard to catch with isolated account-level signals because each account may appear low-risk in isolation. The detection challenge is to connect the subtle overlaps: device reuse, recurring funder accounts, shared legal contacts, address collisions, or a repeated pattern of document anomalies.

Heuristics still matter here. A rules layer can detect impossible combinations such as mismatched jurisdiction and bank country, rapid changes in beneficial owner declarations, or a newly created legal entity requesting high-value purchase rights. But heuristics alone will not scale, especially when legitimate buyers also have complex structures. If you need a practical framing for balancing signal and friction, think of it like optimizing procurement for AI tools: the best outcomes come from a clear outcome model, not from paying for every activity equally. That mindset is similar to what is described in outcome-based pricing playbooks for AI agents.

Payment fraud and settlement abuse

Payment risk in private deals often arrives through wire fraud, account substitution, refund abuse, stolen bank credentials, or third-party funding that violates the marketplace’s rules. Because payment activity is usually low-volume and high-value, traditional velocity checks may not trigger. Instead, attackers exploit the trust around closing windows: urgent instructions, last-minute document changes, and pressure on operations staff to finalize a transfer. The goal is often to get one approved settlement, then disappear before reconciliation catches the mismatch.

In this environment, detection should monitor not only the payment event but the surrounding operational context. Was the beneficiary changed within the last 24 hours? Did the request originate from a device never seen before for that counterparty? Did the email domain or signer identity shift relative to prior closings? These questions behave more like incident response than ordinary payments monitoring. It is useful to borrow from the mindset behind threat-hunting systems that search for patterns under uncertainty, where the absence of a perfect trail does not mean the absence of risk.

Collusion, market manipulation, and side-channel abuse

Private marketplaces also face collusion risks: coordinated buyers and sellers may try to circumvent transfer restrictions, manipulate valuation references, or repeatedly trade assets through connected accounts to manufacture apparent liquidity. This is especially dangerous where price discovery is thin and each transaction can influence future offers. A fraud model should treat these as graph phenomena, not only as transaction anomalies. When counterparties cluster around the same devices, legal agents, or funding sources, the system should surface a ring-level view rather than a single-account score.

For asset categories with mixed on-chain and off-chain representations, you also need to watch side channels that bridge environments. A wallet can be legitimate while the off-chain identity is compromised, or vice versa. Teams working on sensitive crypto workflows often run into the same operational issue around transaction timing and cost dynamics, as discussed in dynamic gas and fee strategies for wallets. The lesson is simple: transaction economics influence fraud behavior, especially when attackers look for the cheapest path to settlement.

3. Data Architecture for Sparse, High-Value Fraud Detection

Build a canonical entity layer first

The most important design decision is not the model architecture; it is the entity model. Every counterparty, signer, beneficial owner, bank account, wallet, device, document set, and asset needs a canonical representation, even if the source records disagree. Use deterministic matching where possible, then probabilistic matching where names, addresses, and identifiers vary. Store all matches with confidence scores and provenance, because the resolution process itself becomes an audit artifact. This is especially important in regulated environments where teams need to explain why two records were merged or kept separate.

A strong entity layer also makes subsequent analytics more effective. Once you can link records across onboarding, settlement, and off-platform documentation, you can build features like “shared beneficiary with a rejected account,” “device used by multiple entities in last 180 days,” or “same law firm across unusually many high-risk closings.” These are not just fraud features; they are operational diagnostics. The architecture resembles the way teams build internal dashboards from external sources in automated intelligence systems: normalize first, analyze second.

Ingest off-chain, OTC, and human review data

Illiquid asset fraud detection fails when it only ingests platform events. You need email metadata, KYC/KYB outputs, wire instructions, signatory events, document hashes, audit logs, support tickets, and manual review outcomes. Human review outcomes are particularly valuable because they carry expert judgments that can be converted into training labels and policy refinements. A rejected transaction may indicate true fraud, but it may also indicate poor documentation, regulatory mismatch, or simple operational error. Your pipeline needs to preserve that distinction.

For teams that manage document-heavy workflows, there is a useful analogy in the way organizations control approvals and template versions. Once a document passes through multiple hands, the system should retain the complete chain of custody, not just the final approved state. That is the same discipline behind approval workflows for signed documents. In fraud analytics, every review note and manual override should be part of the training corpus, not hidden in an operations inbox.

Design for low-label learning

Because confirmed fraud is rare and expensive to validate, the model stack should not rely solely on supervised classification. Use weak supervision, anomaly detection, graph-based scoring, and semisupervised learning to generate candidate risk. Then route high-uncertainty or high-impact decisions to analysts. This reduces false negatives while preserving reviewer time for cases where the model is least certain. It also gives you a way to improve over time without waiting years for a large labeled corpus.

One practical pattern is to combine a baseline rules engine with an ML ranking model and a review workflow. Rules catch hard violations; ML prioritizes ambiguous cases; analysts decide the rest. This layered strategy mirrors the way engineers combine multiple detectors to reduce nuisance alarms. In other safety-critical systems, better detection is often achieved by fusing several weak signals rather than betting on one perfect sensor, a lesson echoed in multi-sensor detection design.

4. Graph Analytics: The Strongest Tool for Identity Abuse

Model entities as a heterogeneous graph

Graph analytics is the right abstraction because fraud in private markets is relational. Build a heterogeneous graph where nodes represent people, entities, bank accounts, devices, emails, documents, wallets, counterparties, and assets. Edges represent observed relationships: owns, signed, funded, accessed-from, submitted-by, approved-by, and transferred-to. The value of the graph is that it captures both direct and indirect associations, enabling you to identify clusters and paths that are invisible in row-based data.

For example, a suspicious pattern may not be a single bad account, but a three-hop chain from a newly registered company to a shared device to a previous denied bank beneficiary. Individually, each node may appear benign. Together, they form a materially stronger abuse hypothesis. This is why graph-based fraud detection often outperforms flat feature tables in environments with sparse transactions and complex identities. It turns “few events per user” from a limitation into a signal advantage, because the graph can extract structure from relationships rather than volume.

Use communities, centrality, and path features

Once the graph is built, use community detection to identify rings, centrality metrics to find bridge entities, and shortest-path analysis to uncover hidden reuse of infrastructure. High betweenness centrality can indicate a service provider or intermediary, but in some cases it points to a mule or broker connecting otherwise isolated fraud accounts. Path features such as “shared device within two hops of denied account” or “same payment rail as previously blocked beneficiary” are often more predictive than raw counts. In illiquid settings, these relational features matter because the transaction count itself is too small to discriminate meaningfully.

Graph embeddings and graph neural networks can improve ranking, but they should be deployed carefully. Sparse graphs can be unstable, and explainability can degrade if you rely on end-to-end embeddings without retaining subgraph evidence. A practical approach is to use graph algorithms for candidate generation and use simpler, explainable models for final risk scoring. If you need a mindset for balancing sophistication with operational clarity, the approach is similar to how teams evaluate analytics maturity across descriptive, diagnostic, predictive, and prescriptive layers in analytics stack design.

Explain graph findings with subgraph evidence

Model explainability is not optional in private markets. When a transaction is blocked or escalated, operations teams need to know which relationships drove the decision. Instead of surfacing a generic “high risk” score, show the subgraph: the shared email domain, the reused wallet, the identical proof-of-address document pattern, or the reuse of a bank account tied to another account under review. This makes analyst review faster and gives compliance teams a defensible narrative.

Pro tip: In low-volume markets, a single strong graph pattern can be more valuable than dozens of weak behavioral features. Prioritize explainable subgraph evidence over opaque score inflation.

5. Heuristics and ML: The Right Division of Labor

Use rules for hard controls, ML for ranking

Do not treat heuristics and machine learning as competing approaches. In illiquid asset fraud, rules are ideal for policy violations, compliance constraints, and high-certainty red flags. Examples include prohibited jurisdictions, beneficiary changes after cutoff, repeated document edits, or impossible identity combinations. ML is better for ranking uncertain cases, detecting drift, and blending many weak signals into a more calibrated risk score. The most reliable systems use rules as guardrails and ML as an adaptive prioritization layer.

This is particularly important when the organization needs operational throughput. If every transaction is sent to manual review, closing times suffer and legitimate clients experience friction. If every transaction is auto-approved, the marketplace becomes vulnerable to abuse. The design goal is to maximize precision at the top of the queue and reserve analyst attention for the highest expected loss cases. That operational balance is familiar to teams that optimize high-stakes workflows such as technical due diligence checklists and high-risk acquisition milestones.

Feature engineering under sparse activity

When transaction volume is low, feature engineering must look beyond simple counts. Good features include time since last identity event, number of distinct counterparties, variance in bank accounts used, document re-submission frequency, change rate in contact details, and graph-derived neighborhood risk. You should also create context-aware deltas such as “new account compared with prior entities managed by same advisor” or “beneficial ownership mismatch relative to prior declared structures.” These features often outperform naive velocity metrics because they reflect the real risk process rather than raw event volume.

Temporal windows should be longer than those used in consumer fraud. In illiquid assets, a six-month or twelve-month lookback may be more useful than a seven-day one. But longer windows also introduce dilution, so you need recency-weighted features and event-specific timelines. The goal is not to capture every signal equally; it is to model the lifecycle of trust. Think of it like building a monitoring view for a volatile market event: what matters is not only how much changed, but when the spike happened and what followed it.

Calibration and thresholding matter more than raw AUC

In many fraud programs, the biggest mistake is obsessing over ROC-AUC while ignoring calibration and decision thresholds. In sparse, high-value environments, a slightly miscalibrated score can create disproportionate harm: too many false positives delay closings, while too few allow high-loss events through. Use calibration curves, expected loss modeling, and segment-specific thresholds by asset class, geography, and counterparty type. A private credit closing should not share the same threshold as a low-value secondary transfer.

Where possible, measure outcomes in business terms: dollars prevented, analyst hours saved, false-positive friction, and average time-to-clear. That is more useful than generic classification metrics, especially when the fraud label itself may be delayed or incomplete. Teams that manage volatile demand in other industries know the same rule: the right metric is the one that maps to a business decision, not just a dashboard. This is why approaches like marginal ROI analysis are useful analogues for deciding where to spend review capacity.

6. Human-in-the-Loop Review: Where the Model Learns

Design reviewers as part of the system, not outside it

Human-in-loop review should not be an afterthought. Analysts need a triage interface that shows the risk score, the features that contributed, the graph neighborhood, and the exact evidence objects behind the alert. They also need fast workflows for dispositioning cases into “fraud,” “legitimate but unusual,” “needs more data,” or “policy exception.” Every disposition should feed back into the model pipeline with timestamps, reviewer identity, and rationale. Otherwise, the organization loses the most valuable signal it has: expert judgment.

This is similar to how high-trust organizations use structured review before sign-off. If each reviewer can see the same evidence trail, decisions become consistent, auditable, and improvable. The operational pattern resembles rigorous approvals in document workflows across multiple teams, where the chain of custody is the product, not just the paperwork.

Use active learning to reduce label scarcity

In sparse fraud environments, active learning is one of the most practical ways to improve the model quickly. Route the cases that are most uncertain, most novel, or most impactful to human reviewers. Then use those decisions to retrain the ranking model and refine the heuristics. This tends to outperform random sampling because it focuses analyst effort on the boundary cases that most improve the decision boundary.

You should also sample some low-risk and clearly benign cases to monitor drift and review consistency. If analysts only see suspicious cases, the label distribution becomes distorted and the model may overfit to only one side of the decision space. In practice, a balanced review program is more durable. It is a little like maintaining healthy signal coverage in monitoring systems: if you only inspect the loud alerts, you miss the quiet failures.

Measure reviewer agreement and override quality

Analyst disagreement is not noise to ignore; it is a signal about policy ambiguity or feature weakness. Track inter-rater agreement, override frequency, and post-review outcomes. If one reviewer repeatedly overturns model flags for a particular asset type, your model or policy probably needs adjustment. If a reviewer’s decisions are consistently confirmed by later investigation, their judgments may be a strong source for higher-weight labels.

For organizations already dealing with platform trust and moderation at scale, the lesson is familiar: human decisions should be measurable, not mystical. The same principle that makes real-time fact-checking operationally effective applies to fraud review. Humans are not there to replace the model; they are there to supply judgment under uncertainty and to improve the system over time.

7. Explainability, Governance, and Auditability

Explain to compliance, operations, and engineering differently

One score cannot satisfy every stakeholder. Compliance wants rationale and evidence. Operations wants speed and clear next steps. Engineering wants feature traces, reproducibility, and model versioning. Your explainability layer should therefore expose multiple views of the same decision. At minimum, provide top contributing features, graph evidence, source records, and the policy rule or model version that triggered the action. Without this, every blocked transaction becomes a manual investigation into the model itself.

Auditability is especially important in illiquid markets because the transaction trail often spans multiple systems. You need immutable logs for model inputs, feature generation, reviewer actions, and final decisions. If those logs are not versioned and queryable, you cannot defend decisions or retrain responsibly. Teams that operate in compliance-heavy environments already know this from managed workflows around validated releases and from the discipline of verification-first engineering.

Use reason codes and evidence packs

Reason codes should be narrow enough to be actionable but broad enough to remain stable over time. Good examples include shared identity infrastructure, beneficiary inconsistency, document anomalies, device reuse, and counterparty graph proximity. Each reason code should link to an evidence pack that shows the specific records, timestamps, and relationship paths involved. This makes audits faster and helps analysts understand whether the system is detecting fraud, policy violation, or genuine edge-case complexity.

Do not let explainability become a cosmetic layer. If analysts cannot use the explanation to decide the next action, it is not enough. The best systems treat explanations as part of the workflow itself: every explanation should answer, “What happened? Why does it matter? What should we do next?” That is the same standard used in rigorous marketplace listing controls, where risk must be surfaced clearly inside the product experience, similar to the way marketplace templates surface connectivity and software risks.

Govern model drift and policy drift separately

Fraud teams often watch model drift, but policy drift is just as dangerous. If the business changes onboarding requirements, settlement rules, or counterparty acceptance criteria, your labels may shift even if fraud behavior does not. Track changes to policy, operational steps, and platform UX alongside statistical drift metrics. Otherwise, the model may look “worse” when the real issue is a changed business process.

That governance discipline pays off most in high-value markets where a small number of transactions can dominate the loss profile. The system should be reviewed regularly, with documented exceptions and postmortems for false positives and false negatives. If you need a useful operational analogy, think of how teams handle cloud supply chain dependencies: every upstream change can affect downstream trust, even when the core code remains intact.

8. A Practical Detection Blueprint for Private Marketplaces

Layer 1: hard rules and policy checks

Start with deterministic controls that stop obvious abuse. Examples include sanctions screening, jurisdiction restrictions, bank-account ownership mismatches, duplicate document hashes, cutoff-time violations, and prohibited counterparties. These rules should be easy to understand and easy to update, because they act as the first line of defense. In private markets, even simple controls can remove a substantial amount of risk if they are consistently enforced.

Rule coverage should be reviewed regularly against observed fraud patterns and false positives. If the same kind of exception is recurring, either the policy is too strict or the attacker is adapting. Good rules are living controls, not static checklists. The operational style is similar to running a disciplined launch or event checklist: you want known failure points surfaced before the closing window, not after. For instance, teams that manage time-sensitive campaigns benefit from systematic readiness thinking like the process in launch checklist-style operations.

Layer 2: ML risk ranking and anomaly detection

On top of rules, use an ML ranker to prioritize cases for review. Train it on a mixture of confirmed fraud, disputed cases, policy violations, and later-confirmed legitimate transactions. Add anomaly detection to catch novel patterns that the label set cannot yet describe. For sparse data, consider one-class methods, isolation-based techniques, and semi-supervised graph models that leverage the entity network rather than just event counts.

Make the model output easy to operationalize. A risk score without a suggested action is hard to use; a risk score with a clear review tier, evidence summary, and reason code is immediately actionable. This is where the model’s real value emerges: not just better classification, but better workflow routing. In practice, many teams find that a simple, well-calibrated ranker beats a complex model that is hard to explain or tune.

Layer 3: human review, escalation, and recovery

High-impact cases should be sent to specialized reviewers who can request more evidence, compare to historical cases, or escalate to legal and compliance. Build explicit recovery workflows for confirmed fraud: beneficiary recall, account freeze, counterparty notice, and post-incident tuning. The goal is not just to detect abuse; it is to minimize loss and improve future decision quality. A fraud program is only complete when it closes the loop from detection to remediation to model update.

For teams expanding into digital asset custody, the same layered approach often applies across other risk classes as well. The controls may differ, but the design principle remains: high-trust assets need strong identity binding, clear approval chains, and evidence-driven recovery. That is why private-marketplace fraud programs often benefit from a broader trust architecture that also considers custody, signing, and operational access.

9. Comparison Table: Fraud Techniques vs. Detection Methods

10. Implementation Checklist for Teams

Data and modeling checklist

First, inventory all sources: onboarding, payments, documents, support, device telemetry, CRM, legal records, and external risk feeds. Second, define a canonical entity schema and a confidence-scored matching process. Third, build graph relationships that can traverse both platform-native and off-platform records. Fourth, create baseline rules for hard policy checks, then train a ranking model on confirmed, disputed, and later-validated cases. Finally, add calibration, drift monitoring, and versioned explanations so that the system can be audited and improved.

Teams should also decide which outputs are user-facing and which are analyst-only. End users do not need to see every internal signal, but they do need clear next steps if action is required. Analysts, meanwhile, need the full evidence pack. This separation keeps the experience usable without hiding the reasons behind a decision.

Operational checklist

Build SLAs for high-risk cases, define escalation tiers, and document when manual overrides are allowed. Train reviewers on both fraud typologies and the meaning of graph evidence. Measure false positive friction, review turnaround, and confirmed-loss reduction. Revisit thresholds by asset class, because a threshold that is acceptable for one market may be intolerable in another. Teams that run complex digital operations know that the best process is one that is measurable, repeatable, and exception-aware, much like robust marketplace risk controls described in risk red-flag frameworks.

Roadmap checklist

As the program matures, add advanced graph embeddings, temporal sequence models, and case-based retrieval for reviewer support. Introduce red-team testing and synthetic fraud scenarios to evaluate whether new attack patterns bypass current controls. Then automate the monitoring of model and policy changes so the team can separate true fraud drift from operational drift. Mature fraud programs are not static; they are feedback systems that learn from every review, every exception, and every blocked closing.

11. Final Takeaways for Fraud and Risk Teams

Design for relationships, not just records

Private-asset fraud rarely reveals itself in one row of data. It emerges through relationships across identities, devices, counterparties, legal entities, and payment rails. That is why graph analytics and entity resolution are not advanced extras; they are the core of the detection architecture. If you only model transactions, you will miss the ring. If you model the network, you can see the structure.

Keep humans in the loop, but make their work cumulative

Human review is essential, but it only works if every decision feeds the system. Capture dispositions, reasons, and evidence so the next model version is better than the last. Treat the review queue as an active learning engine, not as a disposal bin for hard cases. That is how sparse-data fraud programs improve without waiting for large incident volumes.

Prefer explainable wins over opaque complexity

In illiquid asset markets, trust is the product. A model that cannot explain itself will be difficult to deploy, difficult to audit, and difficult to defend when a deal is blocked or a payment is held. The best systems are not necessarily the most complex; they are the ones that combine effective heuristics, strong graph features, calibrated ranking, and clear evidence packs. If you build for explainability from day one, you reduce risk while preserving market velocity.

Pro tip: When in doubt, optimize for the smallest evidence set that can justify the decision. In sparse environments, clarity beats feature bloat.

Where to go next

If your team is building or modernizing this stack, start by mapping the identities and approvals that already exist in your workflow, then connect them into a graph. From there, test a rule-first baseline, add ranking, and use human review to turn scarce labels into a learning asset. For broader context on regulated workflow design and operational trust, you may also find it useful to revisit validated release workflows, trust-and-verification practices, and multi-agent operations patterns that help scale review without sacrificing control.

Related Reading

• AI in Wearables: A Developer Checklist for Battery, Latency, and Privacy - Useful for thinking about privacy and telemetry tradeoffs in constrained environments.
• Website KPIs for 2026: What Hosting and DNS Teams Should Track to Stay Competitive - A strong framework for monitoring operational reliability at scale.
• Cloud Supply Chain for DevOps Teams: Integrating SCM Data with CI/CD for Resilient Deployments - Helpful for understanding upstream dependencies and change tracking.
• How to Build an Integration Marketplace Developers Actually Use - Relevant to designing the connectors needed for fraud data unification.
• Outcome-Based Pricing for AI Agents: A Procurement Playbook for Ops Leaders - Useful when evaluating ML vendors and measuring business value.