Card Record

Card records contain information about plastic cards (ATM, debit, or credit cards) that your financial institution offers to members.

This document contains the field name, field description, field number, mnemonic, data type, and default information for each field. Other pertinent information includes:

**Source**  
Indicates where the data in the field comes from:

    **User-entered**  
    The user creates the information in this field.

    **System-entered**  
    A system process populates the value for the field. This value can include data transmitted by the ATM network, when applicable.

    **System-calculated**  
    The system calculates but does not store the value of the field each time the field appears on an inquiry or file maintenance screen.

The Card record includes the following fields:

Card Type

This field stores a user-defined code to identify the type of card.

Required entry: Enter a user-defined code (00–99) to identify the type of card. The share type lets you group similar types of shares. Each type of card issued by your institution (ATM cards, debit cards, credit cards, etc.) must have a unique two-digit code for this field.

Description

This field stores a card description that appears in card inquiries and on card FM screens when all fields appear.

Enter a description of the card (up to 30 characters). You can add this field to the Card screen definitions.

You can access this field with PowerOn specfiles and SymXchange.

Card Number

This field stores the card number based on the type of card and your defined procedures.

Required entry: Enter the card number (up to 20 characters) based on the following:

• For credit cards or debit cards, the first six digits of the card number must be the bank identification number (BIN) assigned to your financial institution. You can determine the remaining 10 digits.
• For credit and debit cards, the card number must be exactly 16 digits.
• For ATM cards, the first six digits of the card number must be the ISO (International Standards Organization) number assigned to your financial institution.

Tip: If you have set up the Card Creation Wizard Parameters, you can type NEXT instead of a card number in this field. Symitar generates a new card number based on the Card Creation Wizard Parameters for the card type. If you type NEXT for a card type that is not defined in the Card Creation Wizard Parameters, Symitar sets the card number to a blank value.

Card Suffix

This field stores the two-digit suffix to the card number, if any.

Enter the two-digit suffix to the card number, if any. The two most common uses for a suffix are:

• For internal tracking only, you can type a unique suffix to identify each card (for example, 01 for the first card, 02 for the second card, etc.). The card suffix is not part of the Card Number field and is not encoded on the card, but may be useful when designing PowerOn specfiles.
• ATM cards may use a suffix if you issue several cards for the same value in the Card Number field, but want the cards to be treated separately. The suffix is used for card verification. For example, if the ATM card with suffix 01 is blocked and further authorizations will be denied, the ATM card with the same card number and suffix 02 can still be used. The suffix may be part of the card number or may be embossed on the card separately and included in the Track II data in the card’s magnetic stripe.

Note: In the ATM environment, the industry standard recognizes a one-character suffix, also referred to as “member number” or “plastic number.”

This field is not supported in merchant, signature, or credit card environments.

Card Status

This field stores a code that identifies the status of the card.

Required entry: Select one of the following values:

Data Type Descriptions

(0) Not issued

The card has not been issued. If Symitar issues new cards automatically, select this option when you create the Card record and do not revise this field. Symitar updates this field with the appropriate value when you perform a card issuance edit run.

(1) Issued

The card has been issued. If your financial institution issues new cards manually, select this option after you issue the card.

Note: Only cards with this status can be used in the online environment.

(2) Blocked

The card has been issued, but transactions are denied the next time it is used. Some ATM processors/units can physically block the card when it is next used in an ATM. For credit and debit cards, this option is for informational purposes only, and Symitar does not physically block the card. Block credit and debit cards manually.

Note: Certain ATM Terminals may be configured to capture and retain a card during a future ATM transaction when the Card Status is set to this value.

Symitar maintains the value in this field. It also allows ATM network software to update this field whenever that software makes an automatic change affecting it. Under normal circumstances, do not revise this field.

Note: The CPS online authorization software is designed to return specific CPS response codes based on the value in the Block Code field, which takes precedence over this field. This feature automatically occurs for all CPS clients. For further information, see Response Code Out.

If you have the add-on module for automated hot carding, when Symitar receives a file update message from your ATM network processor, Symitar updates this field in all matching Card records. The query includes the Card Suffix if it is enabled for the specific card type.

Status Reason

This field stores a code that indicates why a card was set to (2) Blocked status.

This field lets ATM software translate an internal code to a network-specific code (often referred to as Block Code). This translation is useful in reporting a single card number to multiple networks with different block codes. The ATM network edit does not use this field unless the value in the Card Status field is set to (2) Blocked.

Note: If a card is hot-carded through an incoming Negative File Message from a network, this field is set to 020. A different result can occur for the following conditions:

• If the following are both true:
  • You are using the Falcon Fraud system
  • You have activated the Update Card Status Reason parameter in the Online Network Parameters for the jhaPassPort switch (or if your ATM Online Network Configurations are set to do so) Then the ATM software uses the Response Code from the incoming network negative file messages to automatically populate this field in the Card record according to the following:

    CO-OP/eFunds Network - Response Code	Symitar - Card Status Reason
    41 - Permanent block/lost	001 - Retain-Lost
    34 - Permanent block	003 - Pickup-Fraud
    59 - Temporary block/suspected fraud	103 - Do Not Pickup-Fraud

• If the following are both true:
  • You are using jhaPassPort Direct, version 2008 or greater
  • You have activated the Update Card Status Reason parameter in the Online Network Parameters for the jhaPassPort.pro switch (or if your ATM Online Network Configurations are set to do so) Then the ATM software uses the Response Code from the incoming jhaPassPort Direct online negative file messages to automatically populate this field in the Card record according to the following:

    jhaPassPort Direct - Response Code	Symitar - Card Status Reason
    41 - Hot Card, lost card, pickup	001 - Retain-Lost
    34 - Hot Card, suspected fraud, pickup	003 - Retain-Fraud
    05 - Warm Card, do not honor	100 - Return No Reason Specified
    59 - Warm Card, suspected fraud	103 - Return-Fraud
    The value in this field is then used to automatically populate a specific Response Code in the jhaPassPort Card File (PPCF).

• If the following are both true:
  • You are using the Fiserv EPOC ISO 8583 system
  • You have requested To Host Maintenance (THM) functionality with Fiserv EPOC Then the ATM software uses the Status value and the Capture Code fields from the incoming THM file update messages to automatically populate this field in the Card record according to the following:

    If Fiserv EPOC ISO 8583 THM Status value equals	And Fiserv EPOC ISO 8583 THM Capture Code is 0, Symitar Status Reason equals	But if Fiserv EPOC ISO 8583 THM Capture Code is 1, Symitar Status Reason equals
    0 - Inactive card or card does not exist	000 - Default value	000 - Default value
    1 - Active card	000 - Default value	000 - Default value
    2 - Lost card	101 - Return - Lost	001 - Retain - Lost
    3 - Stolen card	102 - Return - Stolen	002 - Retain - Stolen
    4 - Restricted card	104 - Return - Permanent Restraint	004 - Retain - Permanent Restraint
    5 - Insufficient funds	108 - Return - NSF	008 - Retain - NSF
    6 - Preactivated	000 - Default value	000 - Default value
    7 - Counterfeit	103 - Return - Fraud	003 - Retain - Fraud
    8 - Expired	100 - Return - No reason specified	000 - Retain - No reason specified
    9 - Closed card	100 - Return - No reason specified	000 - Retain - No reason specified

Symitar lets the ATM network software update this field whenever that software makes an automatic change affecting it.

If your financial institution has automated hot-carding, when this field changes on a blocked card, Symitar either:

• Sends a file update message to your ATM network processor, if you have queuing enabled
• Prompts you to send a file update message manually

File Update Manager Exception

This field stores a code that indicates whether the ATM File Update Manager software encounters an exception associated with the card data that it sent or received from the network and gives a general idea (status) about the reason. This indication applies to both high priority messages and messages sent in regular processing.

Data Type Descriptions

0 No Exception

There is no exception for the card.

1 Update Requested by User

The ATM File Update Manager sends an update for the card, usually after fixing an exception that prevented successful messages previously.

2 Deletion Requested by User

The ATM File Update Manager sends a deletion request for the card to the network.

3 Force Add Requested by User (PPS VIP ISO87 only)

The ATM File Update Manager software sends an add request in an outgoing 0382 file update message to the CPS switch. Specifically, the ATM File Update Manager software sends 1 (Add) in the File Update Code message field when you select this option. This File Update Code message field value enables the ATM File Update Manager software to refresh the data in the CPS database with the data in the Symitar account database for a single card. This message field value also enables the CPS switch to do the following:

• Add card data to the CPS database for cards that do no exist in the CPS database
• Update card data in the CPS database if an add request is sent for a card that exists in the CPS database

4–9

Not used.

10 Deleted per User Request

The card was deleted successfully from the network as requested by the user (by previously setting this field to 2 Deletion Requested by User).

11 User Requested Deletion Failed

The ATM File Update Manager tried to delete the card from the network as requested by the user (by setting this field to 2 Deletion Requested by User) and the request failed.

12 Deleted-Data Exception

The ATM File Update Manager indicates that the card was deleted from the network because card or account data were modified in such a way that mandatory data cannot be sent to the network.

13 Deletion for Data Exception Failed

The ATM File Update Manager tried to delete the card from the network because card or account data were modified in such a way that mandatory data cannot be sent to the network, but the request failed.

14 No Update-Rejected by Network

The ATM File Update Manager sent a file update message for the card to the network, but the network has rejected the message.

15 Not Added (Or Deletion in Progress)-Data Exception

The ATM File Update Manager software does not send file update messages for a new card to the network because mandatory data is missing or incorrect. The network does not add the card to the network’s database.

16 To Be Deleted per User Request After Full Refresh Is Complete

The ATM File Update Manager software sets this value if you have requested the deletion (by setting this field to 2 Deletion Requested by User) and a full refresh was started before the ATM File Update Manager could delete the card during regular processing.

17 Not Updated or Added - Data Exception

The ATM File Update Manager software sets this field value to specify that a file update message containing a delete request was not sent to the CPS switch when mandatory data was missing or incorrect for the corresponding card on the Symitar database.

18 Not added (or deletion in progress) - no Share or Loan access

The ATM File Update Manager software sets this field if there are no shares or loans attached to a card, or in the case of jhaPassPort clients, there is no funding account attached to the card. When triggered, if the card was previously reported to the network, the ATM File Update Manager sends a deletion request for the card to the Card Processing Solutions ™(CPS) network.

19 Deleted - no Share or Loan access

The ATM File Update Manager software sets this field when a card has been deleted from the CPS network because no account was attached to it, or in the case of jhaPassPort clients, there is no funding account type linked to it.

20 Deletion for no Share or Loan access failed

The ATM File Update Manager software sets this field when the delete request put forth by 18 Not added (or deletion in progress) - no Share or Loan access fails and thus is unable to progress to 19 Deleted - no Share or Loan access. The ATM File Update Manager removes the card from the archive file and stops sending messages about the card to the network until the File Update Manager Exception field in the Card record is changed to 1 Update Requested by User or 3 Force Add Requested by User.].

Name Type

This field stores a code that Symitar uses to determine the name and address for mailing and embossing instructions.

Required entry: Select one of the following:

Data Type Descriptions

(0) Primary name and address

Cards should be embossed with and mailed to the name and address in the primary Name record for this account.

(1) First Joint name and address

Cards should be embossed with and mailed to the name and address in the first joint Name record for this account.

(2) Separate card name and address

Cards should be embossed with and mailed to the name and address in the Card Name record under this Card record.

Note: You must create a Card Name record under this Card record containing the separate name and address.

Created By User

Symitar stores the user ID and is populated when this Card record is created in this field.

Data Type Descriptions

0–9998

The user ID of the creator of the record.

9999

The system is unable to determine the information because it is not available.

Under normal circumstances, do not revise this field.

Tip: This field is also automatically filled with the User ID upon creation of an Account, Loan, Application, or Card record.

Created At Branch

This field stores the branch ID of the branch where the Card record is created.

Data Type Descriptions

0

The system is unable to determine the information because it is not available.

1–9999

The branch ID where the record was created.

Under normal circumstances, do not revise this field.

Issue Code

This field stores a user-defined code to identify any other information about the card or about issuing the card.

Enter a user-defined code (0–999) to identify any other information about the card or about issuing the card. The use of this field depends on the card issuance edit run written for your card processor. There are several ways to use this field:

• If you offer different colors or designs on your plastic cards, you can use this field to identify the color or design of the card during a card issuance edit run.
• If you have several groups of expiration dates for the cards you issue, you can use this field to identify the expiration group for this card during a card issuance edit run.
• You can use this field to specify that the order is for a card only or a PIN only.

Entering a field value outside of the 0-999 code range results in the following error message: Issue Code must be a number between 0 and 999!

Note: If you plan to use this field, discuss the intended use with us.

Reissue Code

This field stores a code that determines how to reissue a card.

The use of this field depends on the card issuance edit run written for your processor.

Data Type Descriptions

(0) Manual

Allow members to continue using the card they currently have, but prevent a natural reissue request from being sent to your processor (if you control your own reissues).

(1) Automatic

Automatically reissue a plastic card for the number of months specified either in the Reissue Months field or in your card issuance edit. Notification is sent to the processor the number of days before expiration predetermined by your card issuance edit.

(2) Force Card

Reissue a plastic card immediately.

(3) Force PIN

Reissue a PIN immediately. This selection does not issue a new plastic card.

(4) Force Reissue

Reissue a plastic card and PIN immediately.

Reissue Months

This field stores a code that indicates the number of months for which Symitar should reissue the card.

The usage of this field depends on the card issuance edit run written for your processor.

Data Type Descriptions

(0) Use Default Reissue Months

Symitar should reissue the card for the default number of months specified in the card issuance edit run.

1–99

The number of months for which Symitar should reissue the card. This value overrides the default number of months specified in the card issuance edit run.

Instant Issue

This field stores a code that indicates whether the card was an instant issue or not.

Data Type Descriptions

(0) No

The card was not an instant issue (mailed to the member).

(1) Yes

The card was an instant issue (handed over to the member immediately).

For jhaPassPort Direct clients, this field can be used to control which new cards are sent to the network in online messages (in conjunction with the Online File Update Parameter Send New Card Option). For other networks, the field is only informational.

Note: It is your responsibility to populate the field appropriately for instant-issue cards, which might require a change to your card instant-issue application, card default settings, your CARDFM specfile, or your Card Creation Wizard parameters.

Digital Issue Status

This field stores a code that indicates whether the card was digitally issued or whether the request for digital issuance was successful.

All of the field values are applicable to financial institutions using the Visa DPS ISO87 online card interface; however, a subset of the field values can be used by financial institutions with other online card interfaces.

For financial institutions using the Visa DPS digital issuance solution, the system uses the Card Creation Wizard to initiate a digital issuance request when you digitally issue a new or replacement card during the card creation and card block processes. When the Card Creation Wizard finishes the card creation or card block and replacement process for a card type defined for digital issuance, it changes the value in this field from (0) No Digital Issue (Default) to (1) Digital Issue Requested.

Data Type Descriptions

(0) No Digital Issue (Default)

The card was not digitally issued. Only a plastic card may have been issued to the member.

(1) Digital Issue Requested (Visa DPS ISO87 only)

Initiate Symitar to send card information for a digital issuance request in online messages to the online network. Symitar validates data for the card you want to digitally issue before it sends online messages for a digital issuance request.

(2) Digital Issue Pending (Visa DPS ISO87 only)

Symitar changes the field value to this option if the card data is valid. If the card data passes validation, Symitar sends the card data to an internal queue processed by the ATM Network software. The ATM Network software transmits the card data to the Visa DPS online network by sending an outgoing 0382 file update message for each data segment associated with a digital issuance request.

(3) Digital Issue Exception (Visa DPS ISO87 only)

Symitar changes the field value to this option if there is invalid or missing information associated with the card you want to digitally issue. If Symitar sets the field value to this option, it outputs the reason for the exception in the Card record Digital Issue Exception field.

(4) Digital Issue Success - Pending Plastic

For financial institutions using the Visa DPS digital issuance solution, Symitar changes the field value to this option when it receives 00 in the Response Code message field in the incoming 0392 file update message from the online network. This Response Code message field value indicates that the outgoing 0382 file update messages associated with the digital issuance request were successfully received by the online network.

Note: This field value can also be used by financial institutions using a different online card interface to process digital issuance requests.

(5) Digital Issue Reject (Visa DPS ISO87 only)

Symitar changes the field value to this option when the online network rejects the file update messages associated with the digital issuance request. The Response Code message field in the incoming 0392 file update message indicates the reason for failure. If Symitar sets the field value to this option, it outputs the reason for the exception in the Card record Digital Issue Exception field.

(6) Digital Issue Complete

For financial institutions using the Visa DPS digital issuance solution, Symitar changes the field value to this option when you order a plastic card using an edit run. The edit run changes the Digital Issue Status field from (4) Digital Issue Success—Pending Plastic or (5) Digital Issue Reject to (6) Digital Issue Complete to indicate a plastic card has been issued. If Symitar sets the field value to this option but outputs an exception in the Card record Digital Issue Exception field, the card was not digitally issued; only a plastic card was issued.

For financial institutions using the Visa DPS digital issuance solution, if the Online File Update File Type parameter is set to (7) Digital Issue - Switch Managed, (8) Digital Issue - Issuer Managed, or (9) Digital Issue - Issuer Managed - Push Provisioning when the digital ordering process is successfully completed for a digital-only card, the Digital Issue Status field is set to (6) Digital Issue Complete.

Note: This field value can also be used by financial institutions using a different online card interface to process digital issuance requests.

Digital Issue Exception

This field stores the reason for an exception associated with a digital issuance request. Symitar outputs unique text for the exceptions that appear in this field based on invalid or missing information in a corresponding user-defined Account Tracking record or the value in the Response Code message field that it receives from the online network.

Symitar clears this field once you correct the exception and set the Card record Digital Issue Status field back to (1) Digital Issue Requested. If Symitar outputs an exception in this field after it sets the Card record Digital Issue Status field to (6) Digital Issue Complete, the card was not digitally issued; only a plastic card was issued.

Currently, this field is only applicable to financial institutions using the Visa DPS ISO87 online card interface. You cannot revise this field.

Digital Issue Only

This field indicates if the card was created to be digitally issued only.

Data Type Descriptions

(0) No

A physical card should be produced.

(1) Yes

The card has only been digitally issued.

When the Digital Issue Only? field is set to 1 and a user attempts to force ressiue the card, the following warning message appears: The selected Card ending in XXXX is digital only. Do you wish to issue a plastic?. The user can select either Yes or No.

• If Yes is selected, the user is taken back to the Select a card to reissue screen with the card highlighted. The reissue process can be completed as normal, and when done, the Digital Issue Only? field is set to 0. The card is picked up by your institution’s card order process.
• If No is selected, the user is taken to the Select a card to reissue screen and no card is highlighted.

EMV Chip Profile

This field stores the EMV chip profile (network processing options) associated with the card. If this field is non-blank, the card is using the EMV chip.

Block Code

This field stores a processor-defined block code, if any.

Optional entry: Enter a processor-defined block code. This field can be used to store a processor block code if a member’s card should receive special treatment. See the documentation from your card processor for more information on block codes.

Note: The CPS - PPS VIP ISO87 online authorization software is designed to deny transactions based on the value in this field. This feature automatically occurs for all CPS clients. The value in this field takes precedence over the value in the Card Status field, so if this field is set to L (Lost Account), even though the Card Status field is set to 1, transactions will be denied with a CPS denial reason of 43 and a Symitar response of Card Blocked. Since other areas of the Symitar software look at the Card Status field and not the Block Code field, We recommend that you maintain the Card Status field along with the Status Reason Code field to ensure that CPS is notified of any cards that should be blocked for transaction processing while in stand-in.

Note:

• Effective with Symitar Release 2024.01, CPS - PPS VIP ISO87 host-authorized transactions are not denied for cards with the Card Status field set to (1) Issued and a non-blank Block Code field value.
• If you currently use this field for some other purpose, you should consider alternative solutions, and you may want to contact us, depending on the impact this has on other programs.

Reclass Code

This field stores a processor-defined reclass code, if any.

Optional entry: Enter a processor-defined reclass code. See the documentation from your card processor for more information on reclass codes.

Copy Other Card

This field is an action button that allows you to indicate whether you want to copy the field values from another Card record in the same account.

If you choose to copy field values, you can copy field values from any of the other Card records in the same account to save time and keystrokes during creation or revision of a Card record.

1. Click the action button at this field. Symitar displays the Copy Other Card dialog box.
2. Click the drop-down arrow. The drop-down list displays the Card Number and Card Suffix for each existing Card record in the account.
3. Select the card record from which you want to copy field values.
   • Symitar copies the values from the following fields in the specified Card record to the same fields in the Card record you are creating or revising:
     • ATM Count Limit
     • ATM Usage Limit
     • Auth Count Limit
     • Auth Limit
     • Card Number
     • Card Type
     • Chk ID
     • Credit Card Loan ID
     • Credit/Debit Count Limit
     • Credit/Debit Limit
     • Dep Limit
     • Issue Code
     • Limit Amount
     • Limit Days
     • LOC ID
     • Misc Count Limit
     • Misc ID 1–Misc ID 3
     • Misc Limit
     • Name Type
     • PIN Actual
     • PIN Offset
     • POS Count Limit
     • POS Limit
     • Reissue Code
     • Reissue Months
     • Sav ID
     • Service 1–Service 8
     • Warning 1 Code–Warning 20 Code
     • Warning 1 Expiration–Warning 20 Expiration
   • Symitar sets the value in the Card Suffix field of the Card record you are creating or revising to the next available suffix for the value in the Card Type field. If the suffix is part of the card number, Symitar changes the value in the Card Number field to include the suffix.
   • Symitar sets the Name Type field in the Card record you are creating or revising to (2) Separate card name and address when all the following conditions are met:
     • The value in the Name Type field in the record you are copying is (0) Primary name and address.
     • The account already has a Card record with the same card type.
     • The value in the Card Status field in the Card record of the same card type is not (2) Blocked. Note: You must create a Card Name record under this Card record containing the separate name and address.
   • Symitar does not copy the values from the following fields in the selected Card record to the same fields in the Card record you are creating or revising. Instead, Symitar leaves these fields blank:
     • Activation Date
     • Block Code
     • Effective Date
     • Expiration Date
     • Issue Date
     • Prev Card Suffix
     • Prev Expiration Date
     • Prev Number
     • Reclass Code
     • Usage Date
   • Symitar sets the following fields of the Card record you are creating or revising to 0:
     • ATM Count
     • ATM Usage Amount
     • Auth Amount
     • Auth Count
     • Card Suffix
     • Credit/Debit Amount
     • Credit/Debit Count
     • Dep Amount
     • Fee Count 1–Fee Count 4
     • Misc Amount
     • Misc Count
     • PIN Retries
     • POS Amount
     • POS Count
     • Prev PIN Offset
     • Prev PIN Actual
   • Symitar sets the value in the Card Status field of the Card record you are creating or revising to (0) Not Issued. Note: To provide a useful audit trail, Symitar creates a separate entry in account file maintenance history for each field change caused by the Copy Other Card operation.

Sav ID

This field stores the ID of any Share record in the same account that can be accessed through the online environment with this card.

Optional entry: You can enter the ID of any Share record in the same account. Symitar finds the specific share to be accessed through the ATM based on the online ATM edit logic customized for your financial institution.

Tip: You can type an asterisk (*****) to look up an existing share ID and select one, or you can enter a known share ID.

Note: You can request us to change the online ATM edit logic to have Symitar check this field to determine the shares and loans that can be accessed through the online environment. This change lets you issue more than one card to a member (for example, one card to access the prime share and draft share, and other cards to access secondary shares, drafts, or loans). Symitar cannot use these fields until we change your online ATM edit logic.

Chk ID

This field stores the ID of any share draft record in the same account that can be accessed through the online environment with this card.

Optional entry: You can enter the ID of any Share record in the same account with a Share Code field value of (1) Draft. Symitar finds the specific share to be accessed through the ATM based on the online ATM edit logic customized for your financial institution.

Tip: You can type an asterisk (*****) to look up an existing share ID and select one, or you can enter a known share ID.

Note: You can request us to change the online ATM edit logic to have Symitar check this field to determine the shares and loans that can be accessed through the online environment. This change lets you issue more than one card to a member (for example, one card to access the prime share and draft share, and other cards to access secondary shares, drafts, or loans). Symitar cannot use these fields until we change your online ATM edit logic.

LOC ID

This field stores the ID of any line of credit Loan record in the same account that can be accessed through the online environment with this card.

Optional entry: You can enter the ID of any Loan record in the same account with a Loan Code field value of (2) Line of Credit. Symitar finds the specific loan to be accessed through the ATM based on the online ATM edit logic customized for your financial institution.

Tip: You can type an asterisk (*****) to look up an existing loan ID and select one, or you can enter a known loan ID.

Note: You can request us to change the online ATM edit logic to have Symitar check this field to determine the shares and loans that can be accessed through the online environment. This change lets you issue more than one card to a member (for example, one card to access the prime share and draft share, and other cards to access secondary shares, drafts, or loans). Symitar cannot use these fields until we change your online ATM edit logic.

Credit Card Loan ID

This field stores the ID of any credit card Loan record in the same account that can be accessed through the online environment with this card.

You can enter the ID of any Loan record in the same account with a Loan Code field value of (3) Credit Card. Symitar finds the specific loan to be accessed through the ATM based on the online ATM edit logic customized for your financial institution.

Tip: You can type an asterisk (*****) to look up an existing loan ID and select one, or you can enter a known loan ID.

Note: You can request us to change the online ATM edit logic to have Symitar check this field to determine the shares and loans that can be accessed through the online environment. This change lets you issue more than one card to a member (for example, one card to access the prime share and draft share, and other cards to access secondary shares, drafts, or loans). Symitar cannot use these fields until we change your online ATM edit logic.

Misc ID 1–Misc ID 3

These three fields can each store the ID of any Share record or Loan record in the same account that can be accessed through the online environment with this card.

Optional entry: You can enter in each of these fields the ID of any Share record or Loan record in the same account. Symitar finds the specific loan to be accessed through the ATM based on the online ATM edit logic customized for your financial institution.

Note: You can request us to change the online ATM edit logic to have Symitar check this field to determine the shares and loans that can be accessed through the online environment. This change lets you issue more than one card to a member (for example, one card to access the prime share and draft share, and other cards to access secondary shares, drafts, or loans). Symitar cannot use these fields until we change your online ATM edit logic.

Issue Date

This field stores the date the card was first issued or, in some instances, when the Card record was created.

During the first card issuance edit run for the card, Symitar enters the system date in this field. Symitar does not update this field when the card is reissued automatically during a card issuance edit run; this field always contains the date the card was originally issued.

Leave this field blank when creating a new card if you want to produce a plastic card via batch edit and you are issuing the card digitally. If there is a date in the Issue Date field and the Digital Issue Status field is set to (2) Digital Issue Pending, the batch edit will not produce a plastic card and will instead set the Digital Issue Status to (6) Digital Issue Complete.

Under normal circumstances, you should not revise this field.

Effective Date

This field stores the date the card was last issued or reissued.

When you create a Card record, Symitar updates this field with the current system date during each issue or reissue of a plastic (as opposed to PIN-only) by a card issuance edit run.

For manual entries:

• When you open a Card record, the default for this field should be date null so that Symitar can fill in the system date. For procedures, see Card Defaults.
• If you enter a date in this field manually, Symitar overrides the date you enter with the system date each time the card is reissued by a card issuance edit run.
• You must enter an effective date before the value in the Expiration Date field. If you attempt to enter an effective date after the expiration date, Symitar displays the message:
• Cards with an effective date greater than (after) the system date cannot be used in the online environment.

Expiration Date

This field stores the actual date the card expires.

If you leave this field blank (date null), Symitar resets the expiration date during each card issuance edit run that issues or reissues the card. The expiration date is usually the first of the month. For example, a card with a “good through” date of 12/49 would have an expiration date of 1/1/2050 in the Card record. In the online environment, a blank date indicates that the card never expires.

For manual entries:

• If you enter a date in this field manually, the card issuance edit run does not reset the date, unless the date is outside the date limits set for the edit run. This could cause problems if your card processor uses preset expiration dates, so check with us before entering expiration dates manually.
• You must enter an expiration date after the value in the Effective Date field. If you attempt to enter an expiration date before the effective date, Symitar displays the message:

Valid Thru Date

This field displays a system-calculated value in the format <mm/yy>. Users cannot modify this field.

This field’s value is based on the value that the user enters in the Expiration Date field:

• If you enter an Expiration Date value of the first of the month, the calculated value of this field is the prior day, so a 10/1/2028 entry results in a Valid Thru Date of 09/30/2028 and appears on the card as “09/28.”
• If you enter an Expiration Date value between the second and the last day in a given month, the calculated value for this field uses the month and year entered. For example, 10/15/28 results in a Valid Thru Date of 10/31/2028 and appears on the card as “10/28.”

Caution: Before changing the Expiration Date—manually or with the Card Creation Wizard—be sure that you understand the impact it will have with your card processor. Changing the Expiration Date may cause transactions to be declined because the network loses the expiration date the member is currently using (typically the Prev Expiration Date).

Activation Date

This field stores the date the card is considered active.

This field is used in the online environment to determine if a card with a matching expiration date is to be considered active. This date can be set manually, through the audio response software, or via the online environment with the use of a pinned transaction or a card activation message from some ATM networks.

Note: You must request us to customize both the audio response system and the online logic to use this information. The card issuance edit must also be modified.

If you have a card issuance edit run that clears the card Activation Date field when a card is issued or reissued, Symitar places the old contents of the Activation Date field into the Prev Activation Date field.

Close Date

This field stores the date the Card record was closed.

This field lets you close a Card record with a future date without changing the value in the Expiration Date field. This field is useful for temporary cards or if the card is being replaced with a new card, as in a mass issue. This field allows the card to maintain a Card Status value of (1) Issue until the value in the Close Date field is reached. The Daily Posting Batch Program changes the value in the Card Status field to (2) Blocked once the close date is reached.

If the date in the this field is less than or equal to the system date and the card is unblocked, the card will be blocked the next time the Daily Posting batch program runs.

Extra Emboss Line

This field stores a second emboss line on a card order.

You define a second emboss line on a card order only for certain card processors and only if your card edit runs support it.

Last Address Change

This field stores the date of the last file maintenance only when the value in the Name Type field changes.

Whenever you perform file maintenance on the Name Type field, Symitar updates this field in the record you maintained with the system date. To help prevent identity theft, you can use this field to determine if there was a recent change to the Name Type field when a member requests a card.

You cannot access this field for file maintenance.

Record Change Date

Symitar stores the system date in this field when you create, change, or save the Card record. Sometimes Symitar updates this field because the record was saved, even though there may not be any actual changes in the record.

Note: Symitar does not change this field when a calculated field changes.

You cannot perform file maintenance on this field.

PIN Actual

This field can store the actual PIN (personal identification number) used by the processor for this card.

Optional entry: Enter the PIN for this card (000001-999999). The actual PIN does not display during inquiries or file maintenance. During inquiries, 1000000 displays if the value is something other than 0. During file maintenance, 1000000 displays in place of the PIN.

CAUTION:

Caution: You must not enter a number greater than 9999 in this field if your current edit runs and outside card processors do not support PIN fields longer than four digits. Entering a number with more digits than your processor or edit runs support may cause the card to be issued or handled improperly by the outside processor.

Note: There is a Secure Card PINs parameter in the Miscellaneous Parameters. The default setting for this parameter is Y, which masks the contents of the PIN Actual and Previous PIN Actual fields as 1000000 when referenced in a PowerOn specfile. If this parameter is set to N, the contents of these fields are accessible using a PowerOn specfile (We do not recommend this setting, as it is considered a security risk).

CAUTION:

Caution: If you decide to use this field to store your members’ actual PINs, we requires that Jack Henry’s standard Release and Indemnification document be signed and notarized before the field is filled in. In part this document states:

“… releases, discharges and acquits Jack Henry of … any and all contracts, claims, suits, actions or liabilities both in Law and in equity specifically arising from, relating to or otherwise described as and limited to the act of Releasor’s storing of … customer’s actual PINs on Symitar software and any transmissions of said actual PINs … Jack Henry has fully informed Releasor of the various security issues involved in maintaining this information in this manner, …”

PIN Encrypted

This field stores the encrypted value for a PIN (personal identification number). This value depends on the encryption method you use, which can come from the ATM network or a third party.

PIN Offset

This field can store a PIN (personal identification number) offset for this card.

Optional entry: Enter a PIN offset for this card (000001-999999). This field can be used to store a PIN offset, used by card processors to allow members to select their own PINs without knowing the actual PIN (in the PIN Actual field) used by the processor. The PIN offset for a natural PIN (the PIN initially assigned by the issuer) is 0000.

Note: You must not enter a number greater than 9999 in this field if your current edit runs and outside card processors do not support PIN fields longer than four digits (such as for the FDR Star NE ATM Network). Entering a number with more digits than your processor or edit runs support may cause the card to be issued or handled improperly by the outside processor.

PIN Retries

This field can store the number of times someone attempted to enter an invalid PIN (personal identification number) for this card.

Symitar clears this optional field each time a valid PIN is entered.

The card processor usually keeps track of invalid PIN attempts. Symitar allows the proprietary ATM software to update this field whenever that software makes automatic changes.

The Deluxe, MOST, CO-OP, and Quantum card processors offer two options:

• Quick Kill: If this option is turned on, the processor does not forward invalid PIN attempts to your financial institution.
• PIN Validation: If this option is turned on, the processor forwards all PIN attempts to your financial institution. Symitar checks each transaction message and:
  • If the PIN entered for the transaction is valid, Symitar resets this field to 0.
  • If the PIN entered for the transaction is not valid, Symitar adds 1 to this field and disapproves the transaction with the processor code meaningIncorrect PIN Entered. The Quick Kill option must be turned off and the PIN Validation option must be turned on for all attempts to be forwarded for your approval. Symitar allows a specified number (maintained in your ATM configuration file) of consecutive invalid PIN attempts. On the next invalid PIN attempt beyond this number, Symitar disapproves the transaction with the processor code meaning Maximum PIN Tries Exceeded and resets the value in the Card Status field to (2) Blocked.

Note: You must request these options from your processor.

PIN Order Date

This field stores the date the last time a personal identification number (PIN) was ordered.

This field is useful if your financial institution supports a separate card order edit, or for security. You must modify your card edits to update this field each time a card and PIN or PIN only is requested.

Image Reference Number

This field stores the value of a photo reference number for members who create an imaged card background.

This field data identifies the approved image stored by your financial institution or third-party processor. The RB.PPS.IMAGE.REF.UPDATE.FM PowerOn Library specfile updates this field based on incoming data, for clients using PPS VIP ISO87.

This field data should be cleared from the system when the stored card background image is purged by you or the vendor.

Note: Be sure to discuss the amount of time that the data in this field should be stored with your card image vendor. The RB.CLEAR.IMAGE.REF.NUMBER.FM library specfile clears this field.

Clients using the PPS VIP ISO87 card order edit, who wish to begin using this field within the card order process, should contact Symitar Cards Support for modifications to their edit. These modifications may be billable.

Image Reference Date

This field stores the date that an imaged card background was created online.

This date is meant to assist you in identifying your members with imaged cards. This date is also used to assist you in determining when to clear the Image Reference Number field.

Note: This field may be manually updated or used in conjunction with the RB.PPS.IMAGE.REF.UPDATE.FM library PowerOn specfile to read data provided by CPS for newly imaged cards.

Note: Be sure to discuss the amount of time that the data in this field should be stored with your card image vendor. The RB.CLEAR.IMAGE.REF.NUMBER.FM library specfile clears this field.

Clients using the PPS VIP ISO87 card order edit, who wish to begin using this field within the card order process, should contact Symitar Cards Support for modifications to their edit. These modifications may be billable.

This field cannot contain a future date.

Image Reference Issue Count

This field stores the number of times that a card with an imaged background has been issued before the card expiration.

Clients using the PPS VIP ISO87 card order edit, who wish to begin using this field within the card order process, should contact Symitar Cards Support for modifications to their edit. These modifications may be billable.

Prev Number

This field stores the card number value from the previous card when you block and replace that previous card.

This field is typically filled in by a card issuance edit run or by PowerOn file maintenance, not manually.

Prev Card Suffix

This field stores the card suffix value from the previous card when you block and replace that previous card.

This field is typically filled in by a card issuance edit run or by PowerOn file maintenance, not manually.

Prev Expiration Date

This field stores the original expiration date from the Expiration Date field of this card when you reissue this card.

This field is typically filled in by a card issuance edit run or by PowerOn file maintenance, not manually.

Prev Valid Thru Date

This field displays a system-calculated value in the format <mm/yy>. Users cannot modify this field.

This field’s value is based on the value the user enters in the Prev Expiration Date field:

• If you enter a Prev Expiration Date value of the first of the month, the calculated value for this field is the prior day, so a 10/1/2028 entry results in a Prev Valid Thru Date of 09/30/28 and appears on the card as “09/28.”
• If you enter a Prev Expiration Date value between the second and the last day in a given month, the calculated value for this field uses the month and year entered. For example, 10/15/28 results in a Prev Valid Thru Date of 10/31/28 and appears on the card as “10/28.”

Caution: Before changing the Expiration Date—manually or with the Card Creation Wizard—be sure that you understand the impact it will have with your card processor. Changing the Expiration Date may cause transactions to be declined because the network loses the expiration date the member is currently using (typically the Prev Expiration Date).

Prev Activation Date

This field stores the original activation date from the Activation Date field of this card when you reissue this card.

Note: Due to the inclusion of this field, along with the existing Prev Expiration Date field, some changes are required for the following applications:

• The card issue edit must now move the values in both the Activation Date and Expiration Date fields to the Prev Activation Date and Prev Expiration Date fields.
• Upon authorization, the online ATM network edit must check the expiration date on the track II magnetic stripe against the value in the Expiration Date field in the Card record. If they do not match, the edit must then check the value in the Expiration Date field against the value in the Prev Expiration Date field and must also check to see if the value in the Prev Activation Date field was set before authorization.

Prev PIN Actual

This field stores the PIN actual value from the previous card when you block and replace that previous card.

This field is typically filled in by a card issuance edit run or by PowerOn file maintenance, not manually.

Prev PIN Offset

This field stores PIN offest value from the previous card when you block and replace that previous card.

This field is typically filled in by a card issuance edit run or by PowerOn file maintenance, not manually.

Fee Count 1 - Fee Count 4

Each of these four fields can store the current number of a fees for a different type of fee.

These four fields allow you to track up to four different types of fees for each Card record. These fields can be updated through manual file maintenance, PowerOn file maintenance, or edit runs.

Daily Limits

These card fields are related to limits to card transactions for each day.

Usage Date

This field stores the last date when the card was used in an online environment, except for when an online cash deposit is made.

Symitar updates this field with the current Unix date when an online card transaction posts, except for when an online cash deposit is made or a card is used with an invalid PIN. This field is not reset until the card is used again in the online environment on a different Unix date.

Under normal circumstances, you should not revise this field.

Single Usage Max

This field stores the maximum amount allowed for a single cash withdrawal.

Enter the maximum amount (greater than $0.00) for a single cash withdrawal.

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

As of Symitar Release 2025.00, the SymConnect API is fully decommissioned. All clients and vendors are required to transition to SymXchange.

Temporary Limit Start Date

This field stores the date at which a temporary limit begins for ATM, POS, or authorization transactions. The date in this field is used in conjunction with the date in the Temporary Limit End Date field to specify a date range for which the temporary limits are in effect.

You must define a temporary limit for at least one of the previously mentioned transaction types by specifying an amount in the ATM Temp Usage Limit, POS Temp Limit, or Auth Temp Limit fields.

The temporary limit takes effect when the AIX® date equals the date you enter in the Temporary Limit Start Date field. The temporary limits take effect and expire at 12:00 a.m. for the date range you specify in the Temporary Limit Start Date and Temporary Limit End Date fields. To set a temporary limit that is only effective for a single day, you must specify two consecutive dates in the Temporary Limit Start Date and Temporary Limit End Date fields.

Note: To set a temporary limit that is only effective on 05/16/2022, enter 05/16/2022 in the Temporary Limit Start Date field and 05/17/2022 in the Temporary Limit End Date field.

Temporary Limit End Date

This field stores the date at which a temporary limit expires for ATM, POS, or authorization transactions. The date in this field is used in conjunction with the date in the Temporary Limit Start Date field to specify a date range for which the temporary limits are in effect.

You must define a temporary limit for at least one of the previously mentioned transaction types by specifying an amount in the ATM Temp Usage Limit, POS Temp Limit, or Auth Temp Limit fields.

The temporary limit expires when the AIX® date equals the date you enter in the Temporary Limit End Date field. The temporary limits take effect and expire at 12:00 a.m. for the date range you specify in the Temporary Limit Start Date and Temporary Limit End Date fields. To set a temporary limit that is only effective for a single day, you must specify two consecutive dates in the Temporary Limit Start Date and Temporary Limit End Date fields.

Note: To set a temporary limit that is only effective on 05/16/2022, enter 05/16/2022 in the Temporary Limit Start Date field and 05/17/2022 in the Temporary Limit End Date field.

The system performs the following file maintenance after it receives the first online card transaction associated with a transaction type for which you set a temporary limit and the temporary limit is expired: After the temporary limit expires, Symitar reverts to the corresponding standard limit for future transactions that transpire.

• The system resets the ATM Temp Usage Limit, POS Temp Limit, and Auth Temp Limit fields to 0.00
• The system resets the Temporary Limit Start Date and Temporary Limit End Date fields to the default value (blank date)

If temporary limits are removed due to an online transaction that occurred after the limit expired, the temporary limit is not recorded in FM History; however, it is recorded if you modify the Card record manually.

ATM Usage Limit

This field stores the maximum amount that can be withdrawn from an online ATM each day.

Enter the maximum amount that can be withdrawn from an online ATM each day (based on the AIX® system actual date).

Symitar may update this field during a card issuance or balance file edit run.

ATM Usage Amount

This field stores the total amount of all withdrawals based on the value in the Usage Date field from an online ATM.

Each time an online ATM withdrawal posts to this account on the current usage date, Symitar adds the amount of that transaction to this field. This field is not reset or cleared until the card is used again in the online environment on either a new usage date or a new system date.

Under normal circumstances, you should not revise this field.

ATM Count Limit

This field stores the maximum number of online ATM transactions you allow each day.

Enter the maximum number of online ATM transactions you allow each day (based on the AIX system actual date).

ATM Count

This field stores the number of daily ATM transactions, based on the value in the Usage Date field.

Symitar calculates the value of this field. This field is not reset until a new usage date is set.

Under normal circumstances, you should not revise this field.

ATM Temp Usage Limit

This field stores the maximum amount that can be withdrawn from an online ATM each day during the date range specified in the Temporary Limit Start Date and Temporary Limit End Date fields.

The temporary limit you specify in this field takes effect and expires when the AIX® date equals the date you enter in the Temporary Limit Start Date and Temporary Limit End Date fields. The temporary limits take effect and expire at 12:00 a.m. for the date range you specify in the Temporary Limit Start Date and Temporary Limit End Date fields. To set a temporary limit that is only effective for a single day, you must specify two consecutive dates in the Temporary Limit Start Date and Temporary Limit End Date fields.

Note: To set a temporary limit that is only effective on 05/16/2022, enter 05/16/2022 in the Temporary Limit Start Date field and 05/17/2022 in the Temporary Limit End Date field.

The system does not automatically set this field to 0 when the temporary limit expires. The value in this field remains until you manually delete it.

Auth Limit

This field stores the maximum amount that can be authorized for online credit or debit card merchant (signature-based) transactions each day.

Enter the maximum amount that can be authorized for online credit or debit card merchant (signature-based) transactions each day (based on the AIX system actual date).

Account funding transactions can be excluded from authorization limiting for select interfaces.

Auth Amount

This field stores the daily amount of authorizations performed for an online credit or debit card merchant (signature-based) transactions, based on the value in the Usage Date field.

Each time an authorization posts to the account to which this card is associated on the current value in the Usage Date field, Symitar adds the amount of the authorization to this field. It is not reset until a new usage (system) date is set.

Account funding transactions can be excluded from authorization limiting for select interfaces.

Under normal circumstances, you should not revise this field.

Auth Count Limit

This field stores the maximum number of authorizations allowed for an online credit or debit card merchant (signature-based) transactions per day.

Enter the maximum number of authorizations allowed for an online credit or debit card per day (based on the AIX system actual date).

Account funding transactions can be excluded from authorization limiting for select interfaces.

Auth Count

This field stores the number of daily authorizations performed for an online credit or debit card merchant (signature-based) transactions, based on the value in the Usage Date field.

Symitar calculates the value of this field. This field is not reset until a new usage date is set.

Account funding transactions can be excluded from authorization limiting for select interfaces.

Under normal circumstances, you should not revise this field.

Auth Temp Limit

This field stores the maximum amount that can be authorized for online credit or debit card merchant (signature-based) transactions each day during the date range specified in the Temporary Limit Start Date and Temporary Limit End Date fields.

The temporary limit you specify in this field takes effect and expires when the AIX® date equals the date you enter in the Temporary Limit Start Date and Temporary Limit End Date fields. The temporary limits take effect and expire at 12:00 a.m. for the date range you specify in the Temporary Limit Start Date and Temporary Limit End Date fields. To set a temporary limit that is only effective for a single day, you must specify two consecutive dates in the Temporary Limit Start Date and Temporary Limit End Date fields.

Note: To set a temporary limit that is only effective on 05/16/2022, enter 05/16/2022 in the Temporary Limit Start Date field and 05/17/2022 in the Temporary Limit End Date field.

The system does not automatically set this field to 0 when the temporary limit expires. The value in this field remains until you manually delete it.

Misc Limit

This field stores the maximum amount that can be withdrawn from an online environment in miscellaneous transactions each day.

This field is generally used only for clients with an interface to a shared branch network. Enter the maximum amount that can be withdrawn from an online environment in miscellaneous transactions each day (based on the AIX system actual date).

Misc Amount

This field stores the daily amount of all miscellaneous withdrawals, based on the value in the Usage Date field.

This field is generally used only for clients with an interface to a shared branch network. Each time a miscellaneous withdrawal posts to this account on the current usage date, Symitar adds the amount of the transaction to this field. This field is not reset until a new usage date is set.

Under normal circumstances, you should not revise this field.

Misc Count Limit

This field stores the maximum number of miscellaneous transactions per day that your financial institution allows.

Enter the maximum number of miscellaneous transactions per day (based on the AIX system actual date) that you allow. The definition of miscellaneous transactions depends on your online ATM edit and your configuration file.

Misc Count

This field stores the number of daily miscellaneous transactions, based on the value in the Usage Date field.

The definition of miscellaneous transactions depends on your online ATM edit and your configuration file. Symitar calculates the value of this field. This field is not reset until a new usage date is set.

Under normal circumstances, you should not revise this field.

Maximum Check W/D

This field stores the maximum amount allowed for a single withdrawal by check per day.

Enter the maximum amount (greater than $0.00) for a single withdrawal by check.

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Check W/D Limit

This field stores the limit for withdrawals by check per day.

Enter the limit (greater than $0.00) for withdrawals by check per day (based on the AIX system actual date).

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Check W/D Amount

This field stores the total amount of withdrawals by check (greater than $0.00), based on the value in the Usage Date field.

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Check W/D Count Limit

This field stores the maximum number of withdrawals by check allowed per day.

Enter the maximum number of withdrawals by check allowed per day (based on the AIX system actual date).

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Check W/D Count

This field stores the number of withdrawals by check performed, based on the value in the Usage Date field.

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Under normal circumstances, you should not revise this field.

Maximum Transfer

This field stores the maximum amount for a single transfer that your financial institution allows.

Enter the maximum amount (greater than $0.00) for a single transfer.

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Transfer Limit

This field stores the maximum amount that can be transferred each day.

Enter the transfer limit (greater than $0.00) per day (based on the AIX system actual date).

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Transfer Amount

This field stores the total transfer amount (greater than $0.00), based on the value in the Usage Date field.

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Transfer Count Limit

This field stores the maximum number of transfers allowed per day.

Enter the maximum number of transfers allowed per day (based on the AIX system actual date).

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Transfer Count

This field stores the number of transfers performed, based on the value in the Usage Date field.

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Limit Amount

This field stores the maximum amount that can be withdrawn from an offline ATM within the period specified in the Limit Days field.

Enter the maximum amount that can be withdrawn from an offline ATM within the period specified in the Limit Days field. This field is not used for the online environment. It is for informational purposes only.

For some card issuance edits, this field is used to store the credit limit for card mailer instructions.

Limit Days

This field stores the number of days required between withdrawals of the value in the Limit Amount field at an offline ATM.

Enter the number of days (0-9999) required between withdrawals of the limit amount at an offline ATM. This field is not used for the online environment. It is for informational purposes only.

POS Limit

This field stores the maximum amount that can be withdrawn for online, point-of-sale transactions each day.

Enter the maximum amount that can be withdrawn for online, point-of-sale transactions each day (based on the AIX system actual date).

POS Amount

This field stores the total amount of all point-of-sale withdrawals, based on the value in the Usage Date field.

Each time a point-of-sale withdrawal posts to this account on the current value in the Usage Date field, Symitar adds the amount of the transaction to this field. This field is not reset until a new usage date is set.

Under normal circumstances, you should not revise this field.

POS Count Limit

This field stores the maximum number of point-of-sale transactions per day that your financial institution allows.

Enter the maximum number of point-of-sale transactions per day (based on the AIX system actual date) that you allow.

POS Count

This field stores the number of daily (Close Day Processing to Close Day Processing) point-of-sale transactions, based on the value in the Usage Date field.

Symitar calculates the value of this field. This field is not reset until a new usage date is set.

POS Temp Limit

This field stores the maximum amount that can be withdrawn for online point-of-sale transactions each day during the date range specified in the Temporary Limit Star Date and Temporary Limit End Date fields.

The temporary limit you specify in this field takes effect and expires when the AIX® date equals the date you enter in the Temporary Limit Start Date and Temporary Limit End Date fields. The temporary limits take effect and expire at 12:00 a.m. for the date range you specify in the Temporary Limit Start Date and Temporary Limit End Date fields. To set a temporary limit that is only effective for a single day, you must specify two consecutive dates in the Temporary Limit Start Date and Temporary Limit End Date fields.

Note: To set a temporary limit that is only effective on 05/16/2022, enter 05/16/2022 in the Temporary Limit Start Date field and 05/17/2022 in the Temporary Limit End Date field.

The system does not automatically set this field to 0 when the temporary limit expires. The value in this field remains until you manually delete it.

Credit/Debit Limit

This field stores the monetary completion transaction limit per day for an online debit or credit card.

Enter the monetary completion transaction limit (greater than $0.00) per day (based on the AIX system actual date) for an online debit or credit card. “Completions” are the actual credits or debits to be posted to previously authorized transactions.

Note: We recommend that you do not limit the number or dollar amount of completions per day, but rather the number or dollar amount of authorizations.

Credit/Debit Amount

This field stores the daily amount of monetary completion transactions for an online debit or credit card.

Symitar calculates the value of this field. Each time an online completion posts, Symitar adds the transaction amount to this field. Symitar does not reset this field reset until you set a new usage date.

Under normal circumstances, you should not revise this field.

Credit/Debit Count Limit

This field stores the maximum number of monetary completion transactions your financial institution allows per day for an online debit or credit card.

Enter the maximum number of monetary completion transactions that you allow per day (based on the AIX system actual date) for an online debit or credit card.

Note: We recommend that you do not limit the number of completions per day, but rather the number of authorizations.

Credit/Debit Count

This field stores the number of daily transactions for an online debit or credit card, based on the value in the Usage Date field.

Symitar calculates the value of this field. Symitar does not reset this field until you set a new usage date.

Maximum Bill Pmt

This field stores the Maximum amount (greater than $0.00) for a single bill payment.

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Bill Pmt Limit

This field stores the daily bill payment limit.

Enter the bill payment limit (greater than $0.00) per day (based on the AIX system actual date).

Bill Pmt Amount

This field stores the total bill payment amount (greater than $0.00), based on the value in the Usage Date field.

Bill Pmt Count Limit

This field stores the maximum number of bill payments allowed per day.

Enter the maximum number of bill payments allowed per day (based on the AIX system actual date).

Bill Pmt Count

This field stores the number of bill payments performed, based on the value in the Usage Date field.

Maximum Deposit

This field stores the maximum amount allowed in a single deposit.

Enter the maximum amount (greater than $0.00) allowed in a single deposit.

Note: This field is currently used by SymConnect only. The online ATM and credit and debit card environments do not reference it.

Dep Limit

This field stores the aggregate deposit amount per day that is not subject to holds for ATM envelope or check deposits that are not treated as Regulation CC deposits.

• Type 0 to place a hold on all ATM envelope or check deposits that are not treated as Regulation CC deposits.
• Enter the aggregate deposit amount per day (based on the AIX system actual date) that is not subject to holds.

Tip: The ATM Dep Amt Limit Per Card? parameter from the Online Card Parameters must be set to Yes.

Dep Amount

This field stores the total amount of all online ATM envelope or check deposits that are not treated as Regulation CC deposits, based on the value in the Usage Date field.

Under normal circumstances, you should not revise this field.

Deposit Count Limit

This field stores the maximum number of deposits allowed per day.

Enter the maximum number of deposits allowed per day (based on the AIX system actual date).

Note: SymConnect, credit and debit card, and ATM software can use this field to limit deposits. To enable the ATM deposit limiting, set the ATM Deposit Count Limiting? parameter in Online Card Parameters to Yes.

Deposit Count

This field stores the number of deposits performed, based on the value in the Usage Date field.

Note: SymConnect, credit and debit card, and ATM software can use this field to limit deposits. The SymConnect software can also update this field, so if you receive deposits through SymConnect, Symitar accumulates deposits from each software package. To enable the ATM deposit limiting, set the ATM Deposit Count Limiting? parameter from Online Card Parameters to Yes

Enhanced Limiting Fields

There are six enhanced limits. Each limit is configured by setting parameters in Online Card Parameters. These card fields define the limits or store the values to be limited.

Limit 1 Description–Limit 6 Description

These fields display a description of each limit, taken from the Limit 1 Description–Limit 6 Description parameters, which are defined in Online Card Parameters.

Limit 1–Limit 6

These fields store a daily limit amount, which is the total transaction amount allowed for the day, for each limit.

If Symitar processes an online transaction that meets the criteria for a related limit parameter, it checks how much of the limit has already been used that day. If the current transaction will cause the limit to be exceeded, Symitar does the following:

• Declines the transaction
• Responds with a response code that is appropriate for the specific network
• Sets the Our Response Code field in the ATM Dialog record to the following: 2002 – Transaction Exceeds Daily Limit
• Sets the Our Response Detail field in the ATM Dialog record to the following: Card Limit The represents 1–6, depending on which limit parameter is exceeded.

A value of zero in any of these fields is a valid limit, and Symitar denies any transaction that would affect the related limit.

Limit 1 Usage Amount–Limit 6 Usage Amount

These fields store the current total transaction amount approved for each limit.

Whenever the related limit applies to a particular approved transaction and the addition of the transaction amount will not exceed the limit, Symitar adds the transaction amount to the content of this field. If the addition of the transaction amount will exceed the limit, Symitar declines the transaction.

Symitar resets all usage fields when it processes the first transaction for an AIX® date (when the AIX date is not the same as the date in the Usage Date field in the Card record).

Limit 1 Count Limit–Limit 6 Count Limit

These fields store the number of daily transactions allowed for each limit.

Whenever the related limit applies to a particular transaction, Symitar checks how many transactions have already occurred that day. If the current transaction will exceed the allowable number of transactions, Symitar does the following:

• Declines the transaction
• Responds with a response code that is appropriate for the specific network
• Sets the Our Response Code field in the ATM Dialog record to the following: 2022 – Transaction Exceeds Daily Limit Count
• Sets the Our Response Detail field in the ATM Dialog record to the following: Card Limit Count Limit The represents 1–6, depending on which limit is exceeded.

A value of zero in any of these fields is a valid limit, and Symitar denies any transaction that would affect the related limit.

Limit 1 Count–Limit 6 Count

These fields store the current number of transactions for each limit.

Whenever the related limit applies to a particular transaction and the addition of 1 will not exceed the limit, Symitar adds 1 to the current content of the related field. If the addition of 1 will exceed the limit, Symitar declines the transaction.

Symitar resets all usage fields when it processes the first transaction for an AIX date (when the AIX date is not the same as the date in Usage Date field on the Card record).

Limit 1 Per Item Limit–Limit 6 Per Item limit

These fields store the maximum amount allowed for a single transaction for each limit.

Whenever the related limit applies to a particular transaction, Symitar checks whether the transaction amount exceeds the amount in the related field. If the current transaction exceeds the limit, Symitar does the following:

• Declines the transaction
• Responds with a response code that is appropriate for the specific network
• Sets the Our Response Code field in the ATM Dialog record to the following: 2085 – Card Per Item Limit Exceeded
• Sets the Our Response Detail field in the ATM Dialog record to the following: Card Limit Per Item Limit The represents 1–6, depending on which limit is exceeded

A value of zero in any of these fields is a valid limit value, and Symitar denies any transaction that would affect the related limit.

Online Card Issue

For the CPS PPS VIP ISO87 network using the JHA Card Production and Personalization™ solution and the ATM File Update Manager, this field allows the system to specify whether a card was issued using an online file update message. If the card was ordered online, this field would also display the status of the online card order.

For the ACI B24 ISO87 network, this field allows the system to add a card to the network’s database.

Note: This field is only supported for the PPS VIP ISO87 and ACI B24 ISO87 networks.

These are the following data types:

• (0) No Online Issue (Default)
• (1) Online Issue Requested
• (2) Online Issue Rejected
• (3) Online Issue Completed

Online Rush Card Issue

This field determines whether a rush order was requested for the card to be delivered to the cardholder.

Note: Symitar only supports this field for financial institutions that order cards using the following:

• JHA Card Production and Personalization™ solution
• Online Card Ordering
• ATM File Update Manager
• PPS VIP ISO87 online card interface
• ACI B24 ISO87 online card interface

Standard and expedited rush orders increase the delivery speed of the requested card. Expedited rush (same day) orders allow cardholders to receive their requested card faster than a standard rush order for an additional fee. Expedited orders can only be done for cards that were added to QuickAssist before 5:00 p.m. CT the previous day. The order must submitted prior to 1:00 p.m. CT to meet the same-day qualification; otherwise, the order rolls over into next day processing.

These are the following data types:

• (0) No Rush (Default)
• (1) First Class to Cardholder
• (2) First Class to FI
• (3) Certified Mail to Cardholder
• (4) Certified Mail to FI
• (5) Registered Mail to Cardholder
• (6) Registered Mail to FI
• (7) Postal Express to Cardholder
• (8) Postal Express to FI
• (9) Federal Express to Cardholder
• (10) Federal Express to FI
• (11) Saturday Federal Express to Cardholder
• (12) Saturday Federal Express to FI
• (13) DHL to Cardholder
• (14) DHL to FI
• (15) Saturday DHL to Cardholder
• (16) Saturday DHL to FI
• (31) Expedited First Class to Cardholder
• (32) Expedited First Class to FI
• (33) Expedited Certified Mail to Cardholder
• (34) Expedited Certified Mail to FI
• (35) Expedited Registered Mail to Cardholder
• (36) Expedited Registered Mail to FI
• (37) Expedited Postal Express to Cardholder
• (38) Expedited Postal Express to FI
• (39) Expedited Federal Express to Cardholder
• (40) Expedited Federal Express to FI
• (41) Expedited Saturday Federal Express to Cardholder
• (42) Expedited Saturday Federal Express to FI
• (43) Expedited DHL to Cardholder
• (44) Expedited DHL to FI
• (45) Expedited Saturday DHL to Cardholder
• (46) Expedited Saturday DHL to FI

Plastic Count

This field records and tracks the number of cards for a specific Card record.

This field is updated by an increment of 1 for every new card successfully ordered by Online Card Ordering or a batch edit run during the Card record’s history. If a card is created using the Instant Issue option in Card Creation Wizard, the Plastic Count field is set to 1. Contact your Instant Issue vendor and request they update this field for force-reissue requests if you wish to keep a more accurate count.

Data Type Descriptions

0

No physical card has previously been printed or is associated with the Card record. This is the default value.

1–9999

For every new plastic requested and tracked in the Card record’s history, the value of the field increases by 1.

Warnings

These card fields provide user-defined warning and service codes for this card.

Warning 01 Code–Warning 20 Code

These fields can each store a code that identifies a different user-defined warning to apply to this card.

Data Type Descriptions

(0) No Warning Code

No user-defined warning

1–999

A user-defined warning code to apply to this card

You can select up to 20 different warning codes in a Card record.

You can set warning codes to expire automatically by using these fields together with Warning 01 Expiration–Warning 20 Expiration fields.

Warning 01 Expiration–Warning 20 Expiration

These fields can each store a date after which the corresponding warning should no longer apply to the card.

At any of these fields, you can enter a date after which the corresponding warning (see Warning 01 Code–Warning 20 Code) should no longer apply to the card.

For example, if you select 200 at the Warning 9 Code field and type 112811 in the Warning 9 Expiration field, Warning Code 200 will be in effect until the system date reaches November 28, 2011. After that date, the warning is no longer active and the security privileges no longer restrict access to the share.

If you select a value at the Warning 01 Code–Warning 20 Code field, but you do not enter a date at the related Warning 01 Expiration–Warning 20 Expiration field, the warning remains in effect indefinitely or until you remove the value in the Warning 01 Code–Warning 20 Code field manually.

Service 1–Service 8

These fields can each store a code that identifies a different user-defined service offered with the card.

Data Type Descriptions

0

No user-defined service

1–99

A user-defined service code specifies that a particular card has access to a specific service. These service codes are user-defined and can be used by the online environment as well as any edits.

Non-Displayed Fields

These card fields do not appear in Symitar and are only accessed by PowerOn specfiles or SymConnect.

Locator

This field stores a unique number within each member account that can be used as a unique identification of this record.

Symitar automatically assigns the value in this field when the record is created, and you cannot change it. The value is a positive number greater than zero and up to about two billion.

This field can be used during PowerOn file maintenance (both on demand and batch) to uniquely identify a record. Using this field is recommended since a record’s ordinal sequence number may change if someone else inserts or deletes a record with a lower ordinal sequence number just before you post your file maintenance.