Create or replace the screening policy for a vendor
Replaces the whole rule blob, storing it exactly as sent. Send the revision returned by the GET; a stale one is rejected with a 409 rather than overwriting an edit made elsewhere. Omit revision only to create the first policy for this provider. Edits take effect within the policy cache TTL.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
ID of the environment
36^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"95b11417-f18f-457f-8804-68e361f9164f"
Screening provider the policy belongs to
Screening provider a policy belongs to. Deliberately not ProviderEnum, which
is a 44-value auth/social/onramp list of which only these two are screening
providers. The Dynamic sanctions provider is absent because the sanctions floor
is generated from code and is not configurable.
trmWalletScreening, chainalysisAddressScreening Whether this is the sign-in policy or the transaction policy. An environment holds one policy per provider per scope, authored independently. Whether a policy is the sign-in policy or the transaction policy. An environment holds one policy per provider per scope, authored independently — a customer may alert at sign-in and block on transactions, or skip the paid provider call at one and not the other. Two values, not three: an "applies to both" policy would make the overlap with a single-scope row unrepresentable as a unique constraint.
SIGN_IN, TRANSACTION Body
Replaces the whole rule blob. Rules are stored exactly as sent — order preserved, nothing normalized, reshaped, or dropped — because evaluation is first-match-wins and the array order is the policy.
Customer rules, { preScreen, postScreen }, per the provider's own rule schema
(TrmPolicyRules or ChainalysisPolicyRules). Typed as a free-form object
rather than a oneOf over the two: the provider is a path parameter, no
OpenAPI construct selects a body schema from one, and oneOf generates SDK
models that do not compile. The server validates the blob against the
provider's schema before writing, so a TRM policy naming a chainalysis.*
field is a 400. Clients should validate against those two schemas before
submitting.
Neither the sanctions floor nor the terminal ALLOW appears here. Both are generated from code on every screen, so there is nothing to author, edit, or read back, and no request body can weaken them.
The revision this edit was based on. Required to replace an existing
policy, and a stale value is rejected with a 409 rather than silently
applied. Omit it only when creating the first policy for this provider.
x >= 1Response
The stored screening policy
One provider's screening policy in one environment, for one scope.
Screening provider a policy belongs to. Deliberately not ProviderEnum, which
is a 44-value auth/social/onramp list of which only these two are screening
providers. The Dynamic sanctions provider is absent because the sanctions floor
is generated from code and is not configurable.
trmWalletScreening, chainalysisAddressScreening Whether a policy is the sign-in policy or the transaction policy. An environment holds one policy per provider per scope, authored independently — a customer may alert at sign-in and block on transactions, or skip the paid provider call at one and not the other. Two values, not three: an "applies to both" policy would make the overlap with a single-scope row unrepresentable as a unique constraint.
SIGN_IN, TRANSACTION Generation counter. Echo it back on update as the concurrency precondition.
Rule-language version that governs how rules is parsed.
Customer rules, { preScreen, postScreen }, per the provider's own rule schema
(TrmPolicyRules or ChainalysisPolicyRules). Typed as a free-form object
rather than a oneOf over the two: the provider is a path parameter, no
OpenAPI construct selects a body schema from one, and oneOf generates SDK
models that do not compile. The server validates the blob against the
provider's schema before writing, so a TRM policy naming a chainalysis.*
field is a 400. Clients should validate against those two schemas before
submitting.
Neither the sanctions floor nor the terminal ALLOW appears here. Both are generated from code on every screen, so there is nothing to author, edit, or read back, and no request body can weaken them.
Number of live address entries applying to THIS scope — those marked ALL plus those narrowed to it. Entries themselves belong to the (environment, provider) pair, not to this policy.
Whether the policy is live.
ISO 8601 timestamp of the last mutation.