Restrictions

Overview

Restrictions provide a mechanism to block certain transaction activity on an account. For example, if you wanted to block all ACH activity on an account, you could add a restriction which only applied to the ACH rail. If you then wanted to entirely freeze an account, where all activity was blocked, you could add a restriction which applied to all rails.

Partner vs. Internal Restrictions

As the name suggests, a Partner restriction is one that is applied by a Partner user. It is visible to all users and can be modified by both Partner and Internal users. By contrast an Internal restriction is one that is visible to Partner users, but cannot be modified or removed by them. For example, an internal Operations team member may apply an Internal account freeze if they do not want it to be modified by the Partner.

This this division between Partner restrictions and Internal restrictions also applies to holds.

📘

Should I display restrictions to my customers?

Restrictions and holds may be sensitive in nature. Your Implementation Manager (IM) will assist you with your questions on how best to handle customer support issues arising from restrictions or holds.

Restriction Policies

Restriction policies are managed at the product level and define the types of transactions allowed for the program as a whole. Account level restrictions can be applied in addition to these. These policies are not managed by the partner and are configured by the CRB for your product.

Creating Restrictions

Account restrictions work by defining a set of criteria in which the restriction applies to. Null values indicate a wildcard in which any value would match. For example, if we wanted to block all ACH debits over $100 on a master account then the restriction request would look like this:

POST https://sandbox.crbcos.com/core/v1/dda/accounts/200012345/restrictions
{
  "subAccountNumber": null,
  "appliesTo": "All",
  "rail": "Ach",
  "transactionType": "Debit",
  "otherAccountType": null,
  "amountThreshold": 10000,
  "transactionCode": null,
  "reason": "Restricted",
  "notes": "Optional notes here"
}

The more variables are defined in your request the more unique your restriction will be. For example, let's say we placed a restriction similar to the example above but added a value of Incoming ACH in the transactionCode field, like this:

POST https://sandbox.crbcos.com/core/v1/dda/accounts/200012345/restrictions
{
  "subAccountNumber": null,
  "appliesTo": "All",
  "rail": "Ach",
  "transactionType": "Debit",
  "otherAccountType": null,
  "amountThreshold": 10000,
  "transactionCode": "Incoming ACH"
  "reason": "Restricted",
  "notes": "Optional notes here"
}

This restriction would only block all inbound ACH pulls (debits) that are originated via external banks over $100. However, the master account would allow outbound ACH payments to be originated. This is because when inbound ACH payments that are originated via external banks, which COS refers to as paymentType = Origination, the transaction code that is used when the payment posts to your COS account is "Incoming ACH".