# Change a Risk Control Status
source: https://developer.mastercard.com/mastercard-processing-fraud/documentation/use-cases/change-risk-control-status/index.md

## Overview {#overview}

This use case describes how the status of a specified risk control is changed for a cardholder's card. The use case describes one of the scenarios of using `changeRiskControlStatus` API to suspend risk control to improve the cardholder's experience when a transaction is declined due to a specified risk rule.

## Sequence diagram {#sequence-diagram}

Diagram change-risk-control-status

### Explanation {#explanation}

1. The cardholder tries to make a transaction in a country that is defined as a high-risk country in one of the risk rules. The Mastercard Processing Fraud rule engine rejects the transaction and sends the notification to the server. The notification contains the cardholder's card details, transaction details, and risk rule details that declined the transaction.
2. The server sends a notification to the cardholder's mobile application.
3. The mobile application notifies the cardholder that their transaction has been declined due to suspicious activity. The cardholder is asked to confirm recognizing the transaction.
4. The cardholder confirms the transaction.
5. The mobile application sends the request to the server to turn off the risk control that declined the transaction.
6. The server sends a `PUT` request to the `/contracts/{contract_id}/risk-controls/{risk_control_code}/status` endpoint by passing the operation field with the `SUSPEND` value in the request body. Tip: You can use the optional `activationDate` and `deactivationDate` fields in the request body to define the period when risk control will be suspended. For example, you can notify the cardholder that during the next 15 minutes, the transaction can be repeated and define that time in the `changeRiskControlStatus` request with the `activationDate` and `deactivationDate` fields.

   The same API with the `operation` field with the `ACTIVE` value in the request body is used to activate the suspended risk control.
7. The API sends a response to the server confirming that the risk control has been suspended.
8. The server sends a response to the mobile application that the risk control has been suspended.
9. The mobile application notifies the cardholder that the transaction can be repeated. 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.

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}/status`