# Redefine a Risk Control
source: https://developer.mastercard.com/mastercard-processing-fraud/documentation/use-cases/redefine-risk-control/index.md

## Overview {#overview}

This use case describes how an issuer's fraud and risk management team decides to change the default parameters of one of the risk controls enabled for a cardholder's card using their internal fraud and risk management platform.

## Sequence diagram {#sequence-diagram}

Diagram redefine-risk-control

### Explanation {#explanation}

1. During routine transaction monitoring, the fraud and risk team detects unusual activity on one of the cardholder's cards and decides to change its default risk control parameters through their internal back-office system. The back-office system sends the request to the server to change the parameters of a specified risk control for a card generating suspicious activities.
2. The server sends a `PUT` request to the `/contracts/{contract_id}/risk-controls/{risk_control_code}` endpoint by passing new values of the parameters that must be changed in the request body. Note: For the standard product, the server must put the `cardContractId` value in place of `contract_id` in the path. Possible values for the `risk_control_code` parameter are defined during the onboarding process.
3. The API sends a response to the server confirming that the risk control has been redefined.
4. The server sends a response to the back-office system notifying that the risk control parameters have been modified.


Tip: Be aware of the following rules when setting specific values combination of three basic parameters (`maxSingleAmount`, `maxAmount`, and `maxNumber`):

* If you send the request with values for three parameters equal to zero (`maxSingleAmount` = 0; `maxAmount` = 0; `maxNumber` = 0), it will cause the situation when the limit is active but set to zero, so every transaction will be declined.
* If at least one of these three parameters has been set to a non-zero value, the limit will allow transactions up to that value (number of transactions or amount, respectively). When the other two parameter values are set to zero, they will be treated as not existing. ![Three basic parameters](https://static.developer.mastercard.com/content/mastercard-processing-fraud/uploads/activation-and-value-update-1.png)  
  Examples: ![Three basic parameters](https://static.developer.mastercard.com/content/mastercard-processing-fraud/uploads/activation-and-value-update-2.png)

Note: The parameter's value can be changed at any time; additionally, the change can be implemented for a defined period. When the period ends, the value goes back to the default value. When the parameter's value has been changed many times, after each end date, it will go to the value that is still valid and set most recently. It means that it is possible to encapsulate one parameter's value change inside another one, and changes will be automated. Changes can be set in advance with a start date in the future. Changing the value inside a defined period for any time does not prolong the defined 'outer' period. Period endpoints are included, meaning the value is still valid on the end date.

<br />

Refer to [Sandbox testing](https://developer.mastercard.com/mastercard-processing-fraud/documentation/sandbox-testing/index.md) for more information on how to execute the use case in the Sandbox environment.

## Endpoint {#endpoint}


API Reference: `PUT /contracts/{contract_id}/risk-controls/{risk_control_code}`