Case Management: Create Custom Allowlists and Denylists in Predicate

Regulated onchain financial products operate under access controls. AML screening for institutional vault deposits, KYC & KYB for token distributions, investor accreditation for tokenized security liquidity pools – all of these compliance workflows are ways of gating access based on business, regulatory, and legal requirements.

Predicate enables onchain applications to automate these controls with programmable policy. But there will always be edge cases that require specific addresses to be accepted or rejected outside the bounds of the defined policy. For those cases, Predicate offers case management: A system of custom allow/deny lists that compliance teams can edit directly, with updates taking effect onchain instantly.

How it works

Every Predicate policy is a set of rules for who can interact with an onchain product, enforced automatically in real time. For example, a common rule would be to block addresses that appear on the OFAC sanctions list, or addresses that blockchain analytics platforms flag as having exposure to illicit activity. Predicate allow/deny lists enable compliance teams to add a simple binary rule to their policy: Addresses on the allowlist can interact with the product, and addresses on the denylist cannot. 

Updating the lists is easy on the Predicate platform:

Compliance teams navigate to the case management tab of their dashboard and add new addresses to the allow or deny list – either one address at a time or in batches via CSV upload. Each addition gets a memo note explaining why that address or group of addresses was added to the list. The memo field creates an audit trail and gives the rest of the organization context on why that address was allowed or denied. Common examples:

• Pre-screened user addresses added to the allowlist, exempting them from further verification

• Addresses initially flagged as non-compliant with AML rules added to the allowlist after being manually reviewed and verified by the compliance team

• Addresses flagged by law enforcement added to the denylist

Updates to allow/deny lists are propagated in seconds and immediately take effect for onchain enforcement, with no engineering resources required.

Predicate case management versus traditional onchain allow/deny lists

Today, applications and assets can maintain allow/deny lists directly onchain via smart contract updates. Predicate’s approach improves on this in several ways.

No engineering bottleneck for compliance teams

Onchain allow/deny list updates typically require a multisig wallet transaction, which means coordinating signers, submitting the transaction, and waiting for confirmation. In practice, every routine update, even for a single address, runs through engineering. The resulting bottleneck slows down list updates and reduces compliance teams’ ability to act decisively on the risk assessments they’re responsible for. 

Under the Predicate model, the allow/deny lists live offchain, but act as live inputs to the onchain policy enforcement logic. Any authorized team member can update the allow/deny lists from the Predicate dashboard, eliminating multisig coordination delays and empowering the compliance team to enforce their address risk assessments and access policies immediately. Secure, role-based access controls ensure that only designated individuals can update allow/deny lists in Predicate, without the friction of private key management. 

Composable policies, not standalone toggles

Onchain allow/deny lists can do one thing: allow or deny an address access to the product. Predicate's allow/deny lists can fit into more expressive policies that permit or block addresses conditionally. Compliance and product teams can create policies like:

• Allow pre-verified addresses to transact, but only if they also pass AML screening

• Grant approved users early access to the product by creating a policy to deny all transactions before the release date, except for addresses on the allowlist

• Reverify KYC & KYB information by periodically moving addresses to the denylist until the user submits updated documentation

Unlike static onchain allow/deny lists, Predicate's allow/deny lists support the conditional, layered policies real-world finance actually requires.

Allow/deny lists stay private

Onchain allow/deny lists are publicly viewable – anyone can check the chain and see which addresses have been granted or denied access. This visibility can compromise user privacy. For instance, malicious actors could scrape the list of allowed addresses and correlate them with other data sources to unmask users. With Predicate, allow/deny lists stay private, but are still enforceable onchain.

Onchain compliance done right

Case management gives Predicate users a faster, more flexible way to maintain allow/deny lists and integrate them into their broader onchain compliance policy. If you’d like to see Predicate’s allow/deny list features in action, contact us here.