Helix card controls

Purpose

Helix Card Controls allows clients to create program-specific card experiences using card control components rather than prescribed controls, which supports different program use cases, including:

Program risk management: Prevent or limit transaction trends on individual cards or defined segments of a portfolio
Cardholder personalization: Tailor a debit card’s features to an individual cardholder, or align transaction access to a specified product offering
Cardholder applied controls: Expose card control experiences created in a mobile app and allow cardholders to personalize their own debit card experiences

Card controls target the Helix card ID and can be used independently or complementary to other risk management and cardholder personalization services already used through Helix. The suite of services includes:

Service	Description	Target
Card Controls	Allows a program to define the transaction decline logic applied to an individual card ID or PAN, for either program risk management or as part of a card control experience visible to cardholders in an app	Transactions associated with a specific Helix cardID
In Auth	Allows a program to review each transaction individually and decision with Helix, to either decline for risk management purposes or to override and approve for personalizing the cardholder experience	Individual transactions
Custom Fraud Rules (Risk Services Manager)	Allows clients to write fraud rules for a program, which target transactional or fraud trends at the portfolio level by participating in either the Stand Alone, Shared Support, or Self-Service fraud management solutions offered by Helix	Transactions within the portfolio
Managed Real-Time	Baseline set of rules that Visa DPS provides to all processing clients to address global fraud trends	Transactions within the portfolio

Card control components

The card control suite is made up of the following functions:

A card control object that is created using card control components and is applied to the Helix card ID
Personalizing ATM and POS limits using limit group override endpoints in the Helix API
Locking a card from use using the card lock endpoint in the Helix API

Helix control components enable the design of control experiences powered by ISO 8583 transaction message data by creating a card control object. A card control object is assigned to a Helix card ID, and can include any combination of the following:

Transaction type (how the transaction was initiated)
Merchant category code or merchant category groups
Transaction dollar limit
Domestic or international merchant location
U.S. state (for domestic merchants)

For definitions of each card control component, see Card control object component definitions.

More than one control component can be applied to a Helix card ID, all within one card control object, for any combination of use cases.

The same components can be used across different checking and debit card products, including consumer debit cards, parental accounts with youth or allowance cards, and business checking accounts with authorized employee debit card access.

Compatibility

Components can be used in conjunction with one another. Refer to the following table for compatibility between components when used together:

X = Compatible

Complementary Helix API endpoints

In addition to using transaction message data, the Helix API endpoints listed in this section are accessible as features, allowing changes to a card’s daily limits and the ability to lock or unlock a card.

Limit groups

Limit group overrides personalize a cardholder’s daily ATM and POS limits by either increasing or decreasing their daily spending. For example, limit group overrides can be used as part of a larger risk management approach to address higher risk cardholders or behavior by placing them into a high risk limit group.

Limit group	Purpose	Accepted values (Adjusted independently or together)
08 (High risk)	Using card/limit/override, move a cardholder to this limit group to override standard program ATM and POS limits with lower spending limits	An ATM limit lower than the standard program ATM limit A POS limit lower than the standard program limit
09 (Low risk)	Using card/limit/override, move a cardholder to this limit group to override standard program ATM and POS limits with higher spending limits	An ATM limit higher than the standard program ATM limit, and lower than the bank of record approved ceiling A POS limit higher than the standard program limit, and lower than the bank of record approved ceiling

Use of these overrides requires bank of record approval. The bank sets ceilings based on specific use cases as a control for the increase in spending power from the standard program settings.

Limit group overrides can be removed from a cardholder by using card/limit/Reset, which will reinstate standard program ATM and POS limits.

In addition, the card/limit/temporaryoverride endpoint allows temporary daily purchase and ATM withdrawal limits.

Temporary overrides expire the next day at 2:00 am CT.

More information on each endpoint can be found in the Helix API documentation:

For card/limit/override, see Override default card limits.
For card/limit/reset, see Reset card limits.
For card/limit/temporaryoverride, see Create a temporary card limit.

Card lock

Helix offers two types of card lock for debit cards: a temporary lock or a permanent lock. A temporary lock disables the debit card until it is reactivated. Temporary locks can be removed, but a permanent lock disables the card and cannot be undone.

The Helix API endpoint for card lock is card/lock.

For more information card locks, see Lock a card and Unlock a card in the Helix API documentation.

Helix API

A card control object is defined by the Helix API using a JSON object. It is the container for all rules applied to a Helix cardID and can include multiple card control rule objects.

Each card control rule object is a control applied to the Helix cardID, which supports multi-tenancy for any combination of programs applied, or customer-applied rules within the same card control object.

Clients control the hierarchy of card control rules, and each card control rule object is executed in the order it exists within the card control object.

See Card Controls in the Helix API documentation for specific details about the card control object and card control rule object properties.

Creating a card control

Helix Card Controls offers API functionality with the ability to create, list, and archive card controls placed on a Helix cardID. Information on each of these abilities can be found in the Helix API documentation:

For creating a card control object, see Create a card control.
For listing card control objects, see Get a card control and Get a card control by tag.
For archiving card controls objects, see Archive a card control and Archive a card control by tag.

The following error codes specific to Helix Card Controls are applicable to the above API endpoint error responses:

197000: Card control not enabled
192701: Card control not found
192702: Invalid card followed by additional information pertaining to the create
192704: Invalid card control request

Card controls and transaction processing

The standard transaction processing workflow is slightly adjusted with the introduction of Helix Card Controls. However, any transaction decision made before the card control engine will still be honored:

Visa DPS: Transaction processing (PAN, CVV2,PIN, Expiration date match)
Visa DPS: Custom Program Fraud Rules
Visa DPS: Baseline DPS Fraud Rules / Managed Real-Time
Helix: Card Control Engine
Helix: Customer Verifications
Helix: Account Verifications
Helix: Card Verifications

All card control components are available for transaction authorization when Helix is online. However, when Helix is offline and Visa DPS is processing transactions on its behalf (Stand In Processing, or STIP), some components will not be part of the transaction authorization process. Helix must always be online to retrieve, change, modify, or add a new control to a Helix cardID.

See the following table for component availability when Helix is not online:

Control feature	Resides	Helix offline (STIP)
Card Lock	Helix object + DPS	Yes
Limit Group Overrides (high risk limit group)	Helix object + DPS	Yes
Limit Group Overrides (low risk limit group)	Helix object + DPS	Yes
Limit Group Overrides (temporary group)	Helix object + DPS	Yes
Merchant Group Codes	Helix object	No
Merchant Category Codes	Helix object	No
Dollar Limits (per transaction)	Helix object	No
Region (U.S. vs. international)	Helix object	No
Geography (50 U.S. states)	Helix object	No
Entry Mode	Helix object	No

Card controls execute before Helix decisioning logic, in parallel with the future In-Auth Flow logic. A transaction declined by a card control rule will always decline. A transaction with a limit, or that is allowed by a card control rule, follows normal Helix decisioning logic, including account lock, limit group, limit group overrides, balance verification, etc.

A transaction declined by a card control rule will return Response Code 61 (Exceeds Amount Limit) to the payment network. When a transaction matches a transaction rule, Helix will provide detailed information in the card event, realtime card event, and card transaction files:

Card Control Tag
Card Control Rule Tag
Card Control Rule Source
Card Control Result
- 0 = Declined
- 1 = Allowed
- Null = Non-matched control or rule

Additionally, the impacted realtime event file payload types are:

See the following in the Helix API documentation for more information: