--- title: "List account flex controls" method: GET path: "/v1/accounts/{accountId}/flex-controls" tags: ["Account flex controls"] --- # List account flex controls `GET /v1/accounts/{accountId}/flex-controls` ## Request - Base URL: `https://sandbox.pismolabs.io/rules` - URL: `https://sandbox.pismolabs.io/rules/v1/accounts/{accountId}/flex-controls` - Auth: HTTP bearer List the flex controls, given the `accountId`. NOTE: This endpoint requires an account-specific access token. ## Path parameters - `accountId` number, required ## Response `200` OK. Flex controls for the account were found. - AccountFlexControlsResponse[] - `id` string, uuidv4, required: Flex control ID - `deny_code` string, required: Deny code related to restriction. This code is returned when the evaluation does not meet the conditions. - `name` string, required: Flex control name - `type` 'spending_limit' | 'usage_limit' | 'restriction', required: Flex control scope * `usage_limit`: Cumulative flex control that increases by one until `max_limit` * `spending_limit`: Cumulative flex control that increases by the current transaction's `amount` until `max_limit` * `restriction`: Restriction flex control that only validates specified conditions - `rule_reference_id` string: Flex control template ID - `beneficiary_id` string: Account beneficiary ID - `override_controls` string[]: List of existing flex control IDs to override. The platform ignores these controls for the beneficiary identified by `beneficiary_id` and only evaluates the new flex control. - `description` string: Flex control description - `processing_codes` string[]: Processing codes list for evaluating flex control conditions. If the value is empty, the flex control applies to any processing code. - `currency_code` string: Flex control currency code (ISO 4217). Defines the precision used for monetary values such as `max_limit`, `available_limit`, and `condition.value`. - `time_zone` string: IANA Time Zone database, such as "America/New_York". This attribute is used to evaluate the flex control using the desired time zone for condition attributes such as `week_day`, `month_day`, `time_now`, and `reset_period`. If `time_zone` is empty, the control is evaluated using the UTC time zone. - `max_limit` integer: Defines the maximum limit for the control. Its meaning depends on the flex control `type`. * For `spending_limit` controls, `max_limit` represents the maximum spending amount allowed. * For `usage_limit` controls, `max_limit` represents the maximum number of transactions allowed. Once met or exceeded, any subsequent transactions are declined by evaluation control flow. For spending limits, note that this value is an integer. Since global currencies vary in the number of digits that are allowed after the decimal point, you must convert the actual maximum spending limit into an integer value to use in this field. To do this, use the following formula. value = floatNumber × 10^X, where X is the number of digits after the decimal separator for the currency as defined in ISO 4217. For example, if you want to set the value 499.99 for BRL currency transactions, where the number of decimal places is 2, you must set it to `49999` (499.99 × 10²). If you want to set the value 499 for JPY currency transactions, where the number of decimal places is 0, you must set it to `4999` (4999.0 × 10^0 = 4999.0 × 1 - in other words, the value doesn't change.) This field is **REQUIRED** for flex controls with the `type` of `spending_limit` and `usage_limit`, and it does not apply to flex controls with the `type` of `restriction` and `cumulative_limit`. - `available_limit` integer: Represents the remaining limit for the flex control. Its meaning depends on the flex control `type`. * For `spending_limit` controls, `available_limit` is the remaining spending amount. * For `usage_limit` controls, `available_limit` is the remaining number of transactions allowed. The `available_limit` is calculated by: `max_limit` - `current_spend_limit`. The `current_spend_limit`, an internal field, is the total amount of all approved transactions in the `limit_duration` period. It is reset by the evaluation flow when a new transaction is evaluated in the new period according to the `reset_period`. When `available_limit` is set in a PATCH request via [Update account flex control](ref:patch-v1-accounts-flex-control) or [Update customer flex control](ref:patch-v1-customers-flex-control), it resets `current_spend_limit`. In this case, `available_limit` cannot be greater than `max_limit`. For spending limits, note that `available_limit` is an integer. Since global currencies vary in the number of digits that are allowed after the decimal point, you must convert the actual maximum spending limit into an integer value to use in this field. To do this, use the following formula: value = floatNumber * 10^x, where x is the number of digits for the currency as defined in ISO 4217. For example, if you want to set the value 499.99 for BRL currency transactions, you must set 49999 = 499.99 * 10^2. On the other hand, the Japanese money system doesn't use fractions of a yen (the Japanese currency). So, to set the value at 4999 yen, you must set 4999 = 4999.0 * 10^0 = 4999.0 * 1. (In other words, the value doesn't change.) - `conditions` Condition[] - `id` string, uuid: Condition ID - `attribute` 'balance' | 'amount' | 'merchant_category_code' | 'week_day' | 'month_day' | 'time_now' | 'entry_mode' | 'merchant_id' | 'country_code' | 'number_of_installments' | 'is_physical_card_present' | 'is_device_registered' | 'is_tra_exemption_requested' | 'is_pin_validated_offline' | 'authentication_method' | 'is_token_present' | 'initiation_mode' | 'acquirer_country_code' | 'is_cavv_present' | 'avr' | 'operation_type', required: Attribute to evaluate in the condition. * `amount`: Numeric value that indicates the amount of the operation performed by the user * `balance`: Maximum balance amount allowed in an account. Due to fiscal restrictions in some countries, the user cannot have more than a certain amount in the account. When the balance value is defined, the control validates any process of entering money into that account, evaluates the account balance at the time of the transaction, and denies any inflow of money above the amount defined in the balance value. * `country_code`: Three-letter country code (ISO 3166-1) indicating the location where the transaction is initiated or processed. * `entry_mode`: A code used to establish the mode of purchase. Valid only for card network operations. For a control to be valid, it must be a code defined by the entire Field 22 (Visa) or DE 22 (Mastercard) or as specified by each card network. * Visa: Field 22 contains a 4-digit code indicating the method used to enter the account number and card expiration date (positions 1 and 2) and, if an electronic terminal is used, the capability of the terminal to capture online PINs (position 3) and the last digit (position 4) equal to 0 (unused) for transactions processed through VisaNet. This field is fixed-length with three subfields. * Mastercard: DE 22 contains a 3-digit code indicating the method used to enter the account number and card expiration date (positions 1 and 2) and, if an electronic terminal is used, the capability of the terminal to capture online PINs (position 3). * `is_device_registered`: Boolean that indicates whether the device used for the operation is registered according to the financial institution's security policies. * `is_password_present`: Boolean that indicates whether a valid password is present in the evaluation request. Valid only for card network operations. * `is_pin_validated_offline`: Boolean that indicates whether the pin was validated offline in the evaluation request. This is commonly used for offline PIN verification scenarios. Valid only for card network operations. * `is_physical_card_present`: Boolean that indicates whether a physical card is present in the evaluation request. Valid only for card network operations. Digital wallet transactions are treated as physical card transactions. To exclude digital wallet transactions, combine this condition with `is_token_present` as `true`. * `is_tra_exemption_requested`: Boolean that indicates whether a TRA (Transaction Risk Assessment) exemption is requested for the transaction. Valid only for card network operations. * `merchant_category_code`: Merchant Category Code (MCC) is a four-digit number used to describe a merchant's primary business activities. Valid only for card network operations. For a control to be valid, you must enter a code specified by the Mastercard/Visa card network. * `merchant_id`: Merchant ID. Valid only for card network operations. For a control to be valid, you must enter a code specified by the Mastercard/Visa card network. * `month_day`: Day of the month when the operation is performed. Commonly used to limit operations on holidays. The format is MMM-DD. For example, enter January 25 as "JAN-25". * `number_of_installments`: Number of installments in the operation * `time_now`: Restriction window used to establish the time when the operation is performed, defined in the Coordinated Universal Time (UTC 0) zone. For example, a 10:59 PM-06:59 AM window specifies restrictions that apply from 11 PM to 7 AM in the UTC 0 time. * `week_day`: Day of the week when the operation occurs. Use the full lowercase weekday name. Valid values: sunday, monday, tuesday, wednesday, thursday, friday, saturday. * `authentication_method`: Determine whether restrictions should be applied for specific authentication methods. For a control to be valid, it must be a code defined by the Field 60.8/Positions 9-10 for Visa operations or as specified by each card network. Valid only for card network operations. * `is_token_present`: Boolean that indicates whether a token card is present in the evaluation request. Valid only for card network operations. * `initiation_mode`: Payment initiation mode. Valid only for card network operations. - `moto`: Payments made through mail order or telephone. - `mit`: Merchant-initiated transactions. * `acquirer_country_code`: Three-letter country code (ISO 3166-1) representing the location of the acquiring bank or financial institution. Valid only for card network operations. * `is_cavv_present`: Boolean indicating that the CAVV field is present. CAVV stands for cardholder authentication verification value. Valid only for card network operations. * `avr`: String indicating that the transaction is a card network Account Verification Request (AVR) transaction. AVR transactions differ from standard authorizations in that they are typically zero-value and are used for card network verification flows. Currently, the only supported value for this attribute is `mtt`, which is the Mobility & Transport Transaction (MTT) type. * `operation_type`: Type of operation being performed. Allowed values are: - `debit` - debit transaction - `credit` - credit transaction - `none` - transaction that doesn't have a financial impact on the account balance, even though an authorization event occurs. These transactions still exist in the authorization flow, but they don't generate balance movement. AVR (Account Verification Request) is one example of this type of transaction with a zero‑amount authorization. - `operator` 'eq' | 'neq' | 'lt' | 'lte' | 'gt' | 'gte' | 'in' | 'nin' | 'bt' | 'in_group' | 'not_in_group', required: Condition type evaluation * eq - equal to value * neq - not equal to value * lt - lower than value * lte - lower than or equal to value * gt - greater than value * gte - greater than or equal to value * in - includes value * nin - does not include value * bt - between two values * in_group - in attribute group * not_in_group - not in attribute group - `value` string, required: Value to compare - `limit_duration` string: Flex control limit period duration (ISO 8601 format). For example, if a flex control sets a spending limit of $500, and `limit_duration` is set to one month (`P1M`), then the user cannot spend more than $500 from the account in any one month period. - `reset_period` ResetPeriod: Enables the specification of reset periods for accumulators based on the duration in `limit_duration`. When this field is set, it must follow the RFC 3339 pattern from ISO 8601. When `reset_period` changes, the `avaliable_limit` is reset. - `month_day` number: Month day to reset. Can only be used when `limit_duration` is monthly or yearly (in the yearly case, it must be combined with the `month` parameter). - `month` number: Numeric day of the month to reset the flex control. Can only be used when `limit_duration` is yearly. - `week_day` 'monday' | 'tuesday' | 'wednesday' | 'thursday' | 'friday' | 'saturday' | 'sunday': Week day to reset. Can only be used when `limit_duration` is weekly. - `time` string: Time to reset flex control in time zone defined by control. Include only hours, minutes, and AM/PM. For example, `11:00PM` for 11PM or `00:00AM` for midnight. You can use `12` in hours as an alternative to `00` (for example,`12:59AM` is the same as `00:59AM`). - `utc_time` string: *Note: This field has been deprecated, use `time` instead.* Time to reset the flex control in the UTC 0 time. Include only hours, minutes, and AM/PM. For example, `11:00PM` for 11PM or `00:00AM` for midnight. You can use `12` in hours as an alternative to `00` (for example,`12:59AM` is the same as `00:59AM`). - `reset_datetime` string, date-time: The exact date and time of the next reset for the flex control's spending window, in RFC-3339 format. This value is response-only: it is calculated by the platform and is never accepted in requests. When `reset_period` is defined, the reset follows the configured schedule (for example, `month_day: 10` resets on the 10th day of every month). When `reset_period` is omitted, the reset occurs at the control's creation date and time plus `limit_duration`. This value is recalculated whenever an authorization is evaluated. If no authorizations have been processed since the last reset, it may still point to a reset datetime that has already passed. This field is returned only for flex controls with the `type` of `spending_limit` or `usage_limit`. - `active` boolean: If not specified, defaults to 'true'. If set to 'false', the flex control is skipped during evaluation. - `customized` boolean: Indicates whether the flex control is updated at the account level or customer level (`true`) or managed at the program level (`false`). To revert a customized flex control back to program-level management, call [Update account flex control](ref:patch-v1-accounts-flex-control) or [Update customer flex control](ref:patch-v1-customers-flex-control) and set `customized` as `false`. - `response_code` string: Alphanumeric two-character response code. This can be the standard card network response code. When the platform denies a transaction, it returns the response code that provides the precise reason for the denial by the card network. - `custom_code` string: Alphanumeric three-character custom code. This can be an alternative custom code. When the platform denies a control evaluation, it returns the custom code that provides the precise reason for the denial by the anti-fraud solution. - `evaluation_order` integer: Order in which the control is evaluated. If this value is not provided, the control is evaluated after the controls with the configured `evaluation_order` value. ## Other responses - `400`: Bad request. Validation error on request. - `404`: Not found. No flex controls were found for the account. - `500`: Internal server error. --- [API](https://skmtc.dev/pismo/apis/core-platform-flex-controls.md) - [All operations](https://skmtc.dev/pismo/apis/core-platform-flex-controls/llms.txt) - [OpenAPI document](https://skmtc.dev/pismo/apis/core-platform-flex-controls/revisions/f6ad29885c69?raw)