Comparison
Alloy vs ArboRule: identity workflows, or any decision.
Alloy is the strongest product in this comparison at the thing it does. The question is whether the decisions you need to make fit inside what it does.
The short answer
Choose Alloy when
- Onboarding is the problem. KYC and KYB with 270-plus contracted data solutions behind one integration is the deepest identity layer in this comparison by a distance.
- You want to compare and swap vendors without re-integrating. The vendor-neutral model lets a compliance team change which providers get called, in what order, under what conditions, without engineering.
- You need the full safe-change kit and you need it documented. Version history with rollback, backtesting historical data through an updated workflow, A/B testing up to five versions at once, and running a new policy in parallel against live production data.
- Regulatory filing matters. Suspicious activity reports are filed directly with FinCEN from inside their case management.
- You want a documented model path both ways: run yours on their infrastructure as a Lambda, or keep it on your own behind an HTTPS endpoint.
Choose ArboRule when
- The decision is not about identity. Alloy's own documentation scopes journeys to fraud, credit and compliance; pricing, limit assignment beyond underwriting, routing and general policy are outside it.
- You want to know the price. Alloy publishes none and has no self-serve signup; ours is on the pricing page and you can start today.
- You need custom entities and events. Workspace-defined types with their own property schemas let a decision reason over your own history, not only over identity checks.
- The decision runs your own model file. ONNX models execute in-process, immutable and hash-verified at scoring time.
- You want one system for every decision you make, rather than an identity platform plus something else for the rest.
Side by side
Every row links to where it came from.
Claims about Alloy are taken from Alloy’s own documentation, pricing and repositories — never from a review site, and never from us. Follow the link in the left column to check any of them.
| Criterion | Alloy | ArboRule |
|---|---|---|
| Scopedeveloper.alloy.com — journeys read 2026-07-30 | different model Identity, fraud and compliance. Their documentation describes journeys as the core of fraud, credit and compliance decisioning; general non-identity policy such as product pricing or arbitrary business rules is not documented. | Any decision with an input and a verdict. Credit, fraud and onboarding are what it is built for, but nothing scopes a flow to those domains. |
| Pricingalloy.com/contact read 2026-07-30 | not in the product Not published. No pricing page, no tiers, no self-serve signup and no free trial; the only path is a contact form and a demo request. | US$ 500 a month on the Startup plan, including 50,000 decisions across Sandbox and Live. Priced by decision, not by seat. Building and testing is free up to 10,000 decisions a period. |
| Where it runsalloy.com/security read 2026-07-30 | not in the product Cloud only, and they say so plainly: all services run in the cloud on AWS, with no self-hosted or on-premises option. The only customer-hosted element is your own model endpoint. | Hosted only. There is no self-hosted, on-premises or bring-your-own-cloud option, and no published certification — the controls are an append-only audit log, role-based access, scoped API keys, configurable retention and SSO/SCIM. |
| Authoringalloy.com — orchestration and decisioning read 2026-07-30 | in the product A visual, no-code policy builder aimed at risk and compliance teams rather than engineers — build and modify decisioning logic visually, from simple backstop rules to multi-step policies, without engineering resources. Journeys are the multi-step construct. | A visual canvas with 22 node types. Rule, Decision Table, Scorecard and 2D Matrix are grid editors a policy owner can work in; operand fields also accept Python, and the Code node is Python only. |
| Rollout and testingalloy.com — orchestration and decisioning read 2026-07-30 | in the product The most complete in this comparison, and documented: track every workflow change, clone policies for testing and roll back to previous versions; run historical data through an updated workflow in production; A/B test up to five versions simultaneously; run a new policy in parallel against live production data. | Integer traffic weights across published versions, summing to 100, sticky per grouping_id so an application keeps the version it started on. No shadow mode: a challenger serves real traffic or none. Build a dataset from decision history — past requests as inputs, recorded outputs as expectations, every external call pinned to the response the provider actually returned — then run it against any version. Up to 500 cases over a 366-day window, executed serially. |
| Decision historydeveloper.alloy.com — API reference read 2026-07-30 | in the product Every action on a customer record is logged — what data was reviewed, which policy triggered the outcome, who approved it — and evaluations are retrievable later by token with their outcome and outcome reasons, with explicit audit-access endpoints. | Every run stores its input, output, the version that produced it and a node-by-node trace, including each external call's URL, status and latency and each model's SHA-256. Queryable at GET /history/api/v1/decisions. Retention is per-workspace, five years by default. |
| External dataalloy.com/partners read 2026-07-30 | in the product The core of the product: 270-plus data solutions with a vendor-neutral approach, spanning consumer and business identity, fraud intelligence, watchlist screening, authentication and credit, activated from a partner centre in the dashboard. | 28 packaged providers, six databases, and any HTTPS/JSON API through a Custom Connection. You bring your own credentials for each: the platform orchestrates the calls, it does not resell the data. |
| Human reviewalloy.com/compliance read 2026-07-30 | in the product Built-in case management with flexible queues, automatic assignment and customisable filters routing alerts to AML, fraud or risk teams, plus an application queue with saved searches assignable per role. Suspicious activity reports are e-filed with FinCEN from inside it. | A Manual Review node suspends the decision and puts it in a reviewer queue; Case nodes record work without blocking the run. Case queues carry SLA policies pinned onto each case at creation, with business-hours clocks and escalation rungs. |
| Modelsdeveloper.alloy.com — hosted models read 2026-07-30 | in the product Both. They run their own — fraud signal ML and an AI assistant — and will host yours in an Alloy-deployed AWS Lambda in any language Lambda supports, or call yours over HTTPS on your own infrastructure. | ONNX models up to 32 MB, immutable once uploaded and re-verified by SHA-256 at scoring time, executed in-process. One graph input, CPU only. AI and Agent nodes call OpenAI, Anthropic or Google models inside the decision, on your own API key. No key, no AI. |
The rollout row is the one to read twice
Most of this comparison site is about decisioning products that do one or two of versioning, backtesting, A/B testing and shadow mode. Alloy documents all four, publicly, in language specific enough to check: clone a policy for testing and roll back to a previous version; run historical data through an updated workflow in production; A/B test up to five versions simultaneously; run a new policy in parallel against live production data.
ArboRule has weighted traffic across published versions, sticky per case, and replay against recorded decisions with every provider response pinned. It does not have shadow mode — a challenger serves real traffic or none — and it has no one-click rollback; reverting means moving weights back to the earlier version. Alloy is ahead here and it would be dishonest to present the table any other way.
Where we would push back is on the replay. Running historical data through a workflow and running historical data through a workflow with each vendor's original response pinned are different tests. The second isolates the policy change; the first measures the policy change plus however much the vendors' answers have moved since. For a backtest whose conclusion is going to justify a cut-off, that distinction is the whole result.
A replay that re-calls the bureau is not testing your policy change. It is testing your policy change plus six months of somebody else's drift.
Scope is the real decision
Alloy is an identity, fraud and compliance platform. Their own developer documentation describes journeys as the core of fraud, credit and compliance decisioning at Alloy, and nothing documents using it for policy outside those domains.
That focus is why the identity layer is as good as it is. 270-plus contracted data solutions, vendor-neutral so you can compare provider performance and swap without re-integrating, maintained on your behalf — that is a serious asset and the reason to buy them.
The question is what happens to your other decisions. Pricing tiers, credit limit strategy beyond approve and decline, dunning, payout routing, merchant risk, plan eligibility — the decisions a fintech makes that are not about who the customer is. Those either live somewhere else, or they go back into application code, which is where they were before you bought a decision engine.
If onboarding is genuinely the whole problem, that is not a real cost and Alloy is the better product for it. If onboarding is the first of several, buying an identity platform to solve it means having this conversation again in a year.
Entities, and why they change what a decision can ask
ArboRule lets a workspace define its own entity and event types with their own property schemas, and read or write them from inside a flow. That sounds like plumbing and it is actually the difference between a decision that knows only what this request contains and one that knows what this customer has done before.
Velocity rules, repeat-attempt patterns, behaviour since the last decision, anything comparing now against then — all of it needs somewhere to keep the then. In Alloy that state is the customer record as their model defines it. Here it is types you define, so a decision can reason over a concept that only exists in your business.
Worth being precise about one thing: entities and events are off by default and switched on per workspace. They are opt-in, not something every account has running.
Questions
Can Alloy be used as a general decision engine?
Not really, and it does not claim to be. Their documentation scopes journeys to fraud, credit and compliance decisioning across the customer lifecycle, and nothing documents arbitrary non-identity policy such as product pricing or generic business rules. Credit underwriting covers approve, decline and line management; decisions outside identity, fraud and credit are outside the product.
How many data providers does Alloy integrate?
They claim 270-plus data solutions on both their homepage and partners page, spanning consumer identity verification, business verification, fraud intelligence, watchlist screening and monitoring, authentication, and consumer and business credit. The vendor-neutral positioning is the important part: you can compare provider performance and swap one for another without re-integrating.
Does Alloy publish pricing?
No. There is no pricing page, no plan tiers and no self-serve signup or free trial; the only route is a contact form and a demo request. Alloy is also SaaS only — they state plainly that all their services run in the cloud on AWS, with no self-hosted option.
Last verified July 30, 2026 against Alloy’s public documentation. Products change and pages move; if something here is out of date, tell us at hello@arborule.com and we will correct it.