Cryptographically-Bound Vendor Check-Profile Subsetting

Executive Summary

Not every vendor wants every available check run against every transaction - a low-value consumer ACH settlement and a cross-border corporate wire warrant materially different check sets, and running the full library against every transaction wastes compute and can trigger irrelevant review holds. JIL Sovereign's settlement-profile mechanism lets each vendor configure one or more named profiles, each pinning an exact allow-list of check IDs and categories, which the verdict engine filters to before evaluation.

The resolved profile - its ID, vendor, name, and the exact enabled-check list - is embedded in the same canonical payload that gets cryptographically signed alongside the verdict itself, and critically, the checks that were explicitly skipped because they fell outside the profile are also recorded and signed. The resulting receipt proves both what ran and, just as importantly, what didn't and why.

Problem Statement

Multi-tenant compliance platforms that serve vendors across very different settlement types face a tension: running every check against every transaction is wasteful and can produce false holds on checks that are simply irrelevant to a given rail or vendor contract, but letting each vendor configure a custom check subset introduces a documentation problem - if a fraud pattern later surfaces that a particular check would have caught, the vendor needs to be able to prove, cryptographically, whether that check ran at all, and if not, that its absence was an intentional, contracted configuration rather than a platform failure.

Why Simple Filtering Is Insufficient

• Unsigned configuration filtering: a vendor's check subset applied only at request time, with no cryptographic record, cannot later prove which checks were actually in scope for a disputed transaction.
• Only positive results recorded: logging just the checks that ran leaves an ambiguous gap for any check that didn't - was it evaluated and passed silently, or never evaluated at all?
• Profile drift without versioning: if a vendor's profile changes over time, a receipt that doesn't capture the profile version in effect at evaluation time cannot be matched back to the exact configuration that produced it.

Technical Architecture

Named, Cached Settlement Profiles

Each vendor configures one or more profiles - for example, an ACH-consumer-low-value profile and a separate wire-corporate-cross-border profile - each carrying an explicit enabled_checks allow-list and a broader enabled_categories set. Profiles are resolved by ID or by (vendor, name) pair, cached in-process with a short TTL to absorb read load while still picking up administrative edits promptly, and served from a read replica since a profile lookup is a reference-data read rather than a transactional write.

Partitioning Ran vs. Skipped

Binding Into the Signed Attestation

The resolved profile's ID, vendor ID, profile name, sorted enabled-checks list, sorted enabled-categories list, and the profile's own last-updated timestamp are assembled into a profile-attestation object embedded in the same canonical payload used to compute the verdict's cryptographic hash and signature - alongside the sorted list of skipped check IDs. Because both the ran and skipped check sets are inside the signed structure, a vendor's later claim about which checks were or weren't in scope for a given transaction can be verified directly against the signature, without trusting an unsigned log entry.

Prior Art Differentiation

Patent Claim