product assistance for card management

USER GUIDE | PUBLICDocument Version: 1.0 – 2019-02-04

Product Assistance for Card Management

© 2

019

SAP

SE o

r an

SAP affi

liate

com

pany

. All

right

s re

serv

ed.

THE BEST RUN

Content

1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1 Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Card Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1 Lifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Card Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Card Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Editing Cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Renewal of Expired Cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Card Exchange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Card Upgrade/Downgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Card Locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Card Closure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Card Account Linkage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Card Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Limits and Merchant Category Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Details and Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Card Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Restrictions on Merchant Category Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Account Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1 Account Settlement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Interest Free Period. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Budget Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Realization within the Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Creation Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Pay-Off. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Closure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

5 Message Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Base I - Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Base II Clearing and Settlement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2 P U B L I CProduct Assistance for Card Management

Content

5.3 Further Visa Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Balance Inquiry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Visa File Maintenance Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.2 Details and Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Preauthorized Payment Cancellation Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Positive Cardholder Authorization Service (PCAS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Additional Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.1 Emergency Cash. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.2 Force Next Transaction Online. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.3 Fraud Reporting System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Report Fraud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Receive Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.4 Disputes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42Mark Dispute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Receive Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

8 Token Lifecycle Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.2 Details and Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Token Enrollment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Token Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

9 Triggers for Notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Product Assistance for Card ManagementContent P U B L I C 3

1 Overview

Product Information

Product Card management

Release 1.0

Based On SAP Netweaver 7.50

Product Assistance Published On January 2019

1.1 Assumptions

This product assistance guide assumes you have a a basic level of familiarity with the terminology and functions associated with card management. The aim of this document is to provide the information you need to navigate through and optimize the performance of card management. We recommend that you refer to this document whenever necessary during hands-on operation of card management.

1.2 Glossary

Abbreviaiton Term Definition

Base I Base I Electronic real-time authorization system for credit card transactions. First of two phases of Visa's card transaction processing.

Base II Base II Data processing system operated by Visa for the clearing and settlement of card transactions.

PAN Primary Account Number Simply the card number, the card identifier found on payment cards.


Overview

Abbreviaiton Term Definition

PSN PAN Sequence Number Identifies and differentiates cards with the same PAN.

POS Point of Sale Terminal A device which interfaces with payment cards.

PLM Posting Lock Management A component in banking services from SAP that centrally manages the locks of the Account Management system.

PIN Personal Identification Number For payment cards, a numeric password used for authentication.

HCE Host Card Emulation

SE Secure Element

PCAS Positive Cardholder Authoriation Service

A Visa service used to decide about approval, decline or referral of authorization requests in Stand-In Processing (STIP).

STIP Stand In Processing A service in which a 3rd party acts on behalf of the issuer in the authorization process, usually when the issuer is not available.

PVV PIN Verification Values Used in PIN validation.

PVKI PIN Verification Key Indexes Used in PIN validation.

FRS Fraud Reporting System Visa’s centralized clearinghouse that helps clients report, track, and analyze fraudulent transactions. card management exchanges details with FRS using TC 40.

CNP Card-Not-Present Transaction A card payment transaction where the cardholder does not physically present the card to the merchant. Most common are payments over the Internet.

EoD End-of-day procedure A program scheduled to run daily.

VTS Visa Token Service Replaces sensitive account information like PAN with a unique digital identifier (token).

Product Assistance for Card ManagementOverview P U B L I C 5

2 Card Management

2.1 Lifecycle

The solution supports the full card lifecycle from creation to closure. A card status is assigned for each phase in the lifecycle. The supported card statuses and status transitions for each phase are shown in the figure below.

The status transitions supported by the system are listed in Setting the Status of a Card.


Card Management

https://help.sap.com/viewer/2d00ac45c061406785309768a19335bd/9.09/en-US/48e39153b2c2eb23e10000000a174cb4.html

Product Assistance for Card ManagementCard Management P U B L I C 7

2.1.1 Card Creation

Create a card from SAPGUI with transaction BCA_CN_CARD_01 or trigger using service BankCardContractProcessingManageBankCardContractIn and operation CreateBankCardContract. Please refer to the documentation in Account Management for Card Creation for details on entering card data and for the card creation process in general.

The main objective is to create a card record in the system and assign the Primary Account Number (PAN). If connected to an external system, card management also triggers the exchange of embossing details and creates courier data as part of card creation.

The main card creation inputs are:

● Business partner ID of the card holder● Main account to link to the card● Card product

Use

The main purpose of card creation is to create a card record in the system. Part of this process is the assignment of the card's PAN (Primary Account Number). Another part is the generation of embossing and delivery information. Delivery details will be written into a file on the application server. For the embossing details, the processing depends on the output mode defined on the card product for process 0009 - New Creation of Card.

New Creation of Card

If the output code is Direct, the embossing details are exposed to an external component with service consumer BankContractMessageProcessingBankContractMessageOut and operation CreateMessage. If the output mode is Background, a file will be written.


Card Management


RecommendationRefer to the Configuration Guide for details on the set-up of the file generation. The Administration Guide gives guidance on the security related measures.

2.1.2 Card Activation

For card issuers, a decision is needed to deliver cards active or inactive. While card management has a valid card status for Active, for inactive cards you need to make use of card locks. This allows you to directly lock a card for usage after creation. With a card lock all authorization requests are declined. To activate the card, release the card lock.

The decision about the time of activation depends on your business needs. If activated on creation, a user may immediately perform Card Not Present (CNP)-transactions if provisioned with card credentials.

NoteMaking card credentials available to users is not in scope of this release of the solution. You may however retrieve the card number and expiration date using an enterprise service to provision the data to the user with a banking app.

Card management never keeps the Card Verification Value (CVV) which is required to perform CNP transactions. The CVV must also be retrieved from a different source.

Alternatively, you may want to keep cards inactive until successful delivery, or until the user triggers the card activation. Such scenarios are best handled by connecting to an external system that calls service BankLockRequestProcessingBankContractLockRequestIn with operation UpdateLockRequestProcessingDataAsBulk to release a card lock. The external system takes the incoming trigger for an activation.

Refer to chapter Card Locks [page 11]Card Locks

2.1.3 Editing Cards

Use transaction BCA_CN_CARD_02 or service BankCardContractProcessingManageBankCardContractIn with operation UpdateBankCardContract to update card details. The input options are limited since not all card details can be updated.

For details on updating cards, refer to Editing Cards. This documentation provides information on authorizations and control principles for card updates.



2.1.4 Renewal of Expired Cards

Card management uses a renewal run to renew expiring cards. All cards near their expiration date are selected and unless conditions prevent it, the card is renewed. For example, if a renewal lock is placed on the card it is not considered. A configuration defines the amount of time before the expiration date used to select cards for the renewal run.

There is an enhanced selection mode that provides more control over the renewal process. In this mode, the cards identified as close to expiry are renewed only if explicitly flagged for renewal. You manually set the Ready for Renewal flag using SAPGUI or a service call.

ExampleYou want to evaluate card usage before renewing a card. If a card is not actively used you may want to get in touch with the user before renewing the card. Based on the outcome, you may flag the card for renewal or omit it. You can custom build the required logic within the card solution, or in an external solution which exchanges all the details using service calls.

See additional information about Renewal Run to understand the configuration and processing of the program.

2.1.5 Card Exchange

Card management supports different types of card exchanges:

● ReplacementReplacement cards with a new PAN and PAN Sequence Number (PSN) are provided if a card is lost or stolen.

● Early RenewalEarly renewal cards are created with the same PAN as the preceding card but with a new PSN for cases like a damaged card.

● DuplicateDuplicate cards get the same PAN and PSN as the original card.

You trigger card exchanges using either SAPGUI or with service calls. If using SAPGUI, select the card exchange type from the available options. Note that each exchange type has specific prerequisites; see Exchange Card in the SAP Help for details.

For the service based requests, use the service BankCardContractProcessingManageBankCardContractIn with operation ReplaceBankCardContract for a replacement, and operation RenewBankCardContract for an early renewal. The creation of duplicates using a service request is not supported; if duplicates are required, you must use SAPGUI.


Card Management

https://help.sap.com/viewer/2d00ac45c061406785309768a19335bd/9.09/en-US/f0e89153b2c2eb23e10000000a174cb4.html

https://help.sap.com/viewer/2d00ac45c061406785309768a19335bd/9.09/en-US/4793fa0d26481149e10000000a421937.html

2.1.6 Card Upgrade/Downgrade

To upgrade or downgrade a card, make use of the Product Change process. A card upgrade or downgrade not only changes the card product, such as from a gold card to a platinum card, it also updates the product version which activates or deactivates specific features of the card.

2.1.7 Card Locks

You can lock a card using the component Posting Lock Management, which sets locks on cards, card features and also on accounts and business partners. In Posting Lock Management (PLM), locks are represented using PLM Documents. A PLM Document defines the type of lock to set by stating an Event Type, defines the objects to set the locks on (card, account, business partner) and maintains the status of a lock.

NoteThis document will only focus on card-related locks.

2.1.7.1 Setting a Lock

Lost or stolen cards are the main reasons to lock a card. When a card is locked, all incoming transactions (authorization requests) are declined. Depending on the features included in the lock, it may also prevent lifecycle activities like card renewal.

A card lock may remain locally at the issuer or get populated to Visa. You would typically keep a lock local if the user is optimistic on finding the card again. For a card permanently lost or stolen, you would populate to Visa so that Visa can return a non-standard response during stand-in processing.

When a lock is populated to Visa the card is placed into Visa's Exception File with a related non-standard response. The Visa update is done automatically based on a configuration that defines a non-standard response per Event Type.

If a Visa update is configured, the solution automatically sends an update to Visa's exception file once a PLM Document is created and set active. Similarly, once a PLM Document is set to inactive or closed, an update to Visa is sent to remove the card from the exception file.

Updates to the exception file can also be triggered manually. Please see chapter Exception File [page 36]Exception Files for related details.

2.1.7.2 Releasing a Lock

You release a lock by setting the status of a PLM document to Inactive or Closed.


https://help.sap.com/viewer/2d00ac45c061406785309768a19335bd/9.09/en-US/4793fa0d26481149e10000000a421937.html


If a Visa update for the lock's Event Type is configured, an update to delete the card from the Exception File is triggered with release of the lock. This does not affect any manual card additions to the Exception File. In such a scenario, a notification can be set up to notify users.

NoteSetting up a notification requires ABAP development.

ExampleA service user manually adds a card to the Exception File. The card is then locked, and for the lock's Event Type, an update to the Exception File is configured. As the card is already exists in the Exception File, no update occurs on setting the lock. On unlocking, the card is deleted from the Exception File. If a notification is implemented, the service user may receive an alert and then re-add the card to the Exception File.

2.1.8 Card Closure

In card management, a card is closed if it has a status which does not allow any further status change. The following list describes all such statuses and how to set them:

● Order CanceledTo cancel a card order go to the SAP Easy Access screen and choose Financial Services → Account Management → Card → Card Master Data → Cancel Card Order (transaction BCA_CN_CARD_30) . This is only for cards in status Scheduled for Data Transfer.

● ExpiredA card automatically expires when it reaches expiration date. No explicit process is required to get there.

● DestroyedTrigger the systemic card destruction using the SAP Easy Access screen, choosing Financial Services → Account Management → Card → Card Master Data → Destroy Card (transaction BCA_CN_CARD_18). This process is only supported for cards in status Returned. To mark a card as Returned use Financial Services → Account Management → Card → Card Master Data → Return Card (transaction BCA_CN_CARD_16).

2.2 Card Account Linkage

Card management restricts the linkage of cards and card accounts as follows:

● Only one primary card is allowed per account● In addition to the primary account, two accounts of different types can be linked to a card:

○ For a credit card, linkage to one current and one saving account is possible○ For a debit card, linkage to one credit account and one current or savings account, depending on the

type assigned to the primary account


Card Management

NoteThese restrictions are system restrictions. Please consider local rules and regulations concerning allowed account linkages. For example, it may be forbidden to link a debit card to a credit card account.

A general rule is that all accounts linked to a card have to share the same account holder. Plus, the card holder has to be the same business partner as the account holder of the card's primary account.

2.3 Card Security

Make sure to set up your environment to comply with PCI-DSS. Do also consider all rules and regulations on data privacy and security that apply to your installation.

For details on making card management secure, refer to the Installation Guide for Card Management.

See also Security Settings Card Numbers

NoteConfiguration is required to set up encryption of sensitive data.


https://help.sap.com/viewer/2d00ac45c061406785309768a19335bd/9.09/en-US/2ea7a31c4e4d40bf8cd22f3f5109e0ad.html

3 Limits and Merchant Category Restrictions

3.1 Introduction

Card management restricts card charges by placing credit limits at the business partner, account and card level.

You define the the total commitment amount at the business partner level. This amount is usually distributed among the different accounts held by the business partner.

You set pre-defined as well as custom limits at the account level. Details are provided in Editing Limits.

At the card level there is a flexible framework to define limit categories and set defaults. This allows users to assign and unassign limit categories on individual cards.

3.2 Details and Execution

3.2.1 Card Limits

The limit framework requires the set-up of limit categories and product defaults. Afterwards, limits are assigned to individual cards.

3.2.1.1 Operations

Before you can set up limit categories, you must first define operations. An operation usually combines one or more transaction types and prenote types. These combinations of types separate the different types of card transactions, like an international cash withdrawal or a CNP purchase.


Limits and Merchant Category Restrictions

https://help.sap.com/viewer/2d00ac45c061406785309768a19335bd/9.09/en-US/2cea9153b2c2eb23e10000000a174cb4.html

NoteAn exception is the operation you define for an overall limit, where no transaction types or prenote types are required.

Operations

3.2.1.2 Limit Categories

Limit categories define the types of limits and are based on the following parameters:

● An operation, which specifies the type of card transaction to set limits● The granularity of the limit

Limit Categories

The granularity defines if the limit relates to:

● A specific transaction● A revolving period, where the solution supports daily, weekly and monthly● A fixed period, where only a month is supported.

Product Assistance for Card ManagementLimits and Merchant Category Restrictions P U B L I C 15

Utilization is always calculated for the first to the last day of the month and then reset● The overall amount to spend on a card● The amount allowed to spend on budget

3.2.1.3 Limit Profiles

Limit Profiles define the Limit Categories a product supports. You assign the Limit Categories supported for each card product. The bank or user can then set limits only for the Limit Categories assigned to a product. Defaults are also defined using Limit Profiles. A Limit Profile contains the following details:

● The default limit amount.● The limit range with the minimum and maximum amount. If you later want want to not allow a change of

the limit, set the minimum and maximum amount to the same value.● Indicate if the category should automatically be assigned to each new card created with the related

product. If not, the Limit Category can be assigned after creation of the card.

NoteYou will not be able to assign a Limit Category to a card if the Limit Category is not assigned to the Limit Profile which is assigned to the card's underlying product.

3.2.1.4 Set Card Limits

Setting limits on cards is supported using SAPGUI and service calls. With service calls, both client servicing and customer self-servicing are covered.

Only limits defined in the card product's Limit Profile can be set for a card. The value of the limit also needs to fit into the range defined in the Limit Profile, if any.

3.2.1.5 Set Master Limits

The solution offers Master Limits as a means to temporarily overwrite card limits. You set a Master Limit per limit category and define a period for which the Master Limit is valid. During this period, the value of the Master Limit is checked instead of the corresponding card limit.

Master Limits are considered as hierarchical. Should you define an overwrite on the limit granularity 'Daily', the solution approves transactions that still fit into the overwrite, even if the value is above a card limit set on weekly or monthly granularity.


Limits and Merchant Category Restrictions

3.2.2 Restrictions on Merchant Category Codes

Merchant Category Codes specify categories of merchants such as Office Supplies, Dog Grooming Services, Household Appliance Stores, etc. These codes specify the card behavior based on a blacklist or whitelist assignment. Transactions for Merchant Category Codes on a blacklist are declined while categories not listed are approved, provided any other conditions required for approval are fulfilled. For a whitelist, only the merchant categories assigned will approve card transactions while categories not listed are declined.

Product Assistance for Card ManagementLimits and Merchant Category Restrictions P U B L I C 17

4 Account Management

4.1 Account Settlement

4.1.1 Interest Free Period

Card management supports interest free periods. Interest free periods offer clients interest free transactions if they repay the full amount outstanding within a given time after settlement.

The following rules and restrictions apply to the interest free processing:

● Interest free applies to periods and not individual transactions. It is realized by setting zero conditions.● The decision if an interest free period is applied is taken with standard settlement means. A new end of day

procedure is introduced that executes on settlement date and prepares the accounts accordingly. The end of day procedure is implemented in report /CRDBS/DM_ACCNT_IND_COND_EOD.

● Based on the account’s outstanding balance and repayments the end of day procedure will either set new individual zero conditions or delete existing individual zero conditions of already settled periods.

● The length of the interest free period is defined by the length of a settlement period plus the number of days after settlement in which client has to repay the amount outstanding.

ExampleIf a settlement period has 30 days, and client has to repay the amount outstanding within 25 days after settlement, an interest free period of maximum 55 days results.

Card management separates transactions that always accrue interest (cash) from transactions that are eligible for the interest free period (non-cash). The separation is realized by different turnovers for cash and non-cash. In order to handle the separation, a new turnover class is introduced: turnover class for debit cash transactions.

Two new calculation bases need to be assigned to the appropriate financial condition types. One calculation base is responsible for calculation of "cash" calculation bases. A second one is for "non-cash" bases. Refer to the Configuration Guide for details on setting up the calculation bases.


Account Management

4.1.1.1 Functionality

Periods

The procedure to determine interest free periods often spans several periods. In the context of interest free and the corresponding end of day procedure the terms are used in the following way:

Term Definition

End of previous period Last day of latest settlement period

Start of current period Day after last day of latest settlement period

End of current period Last day of current settlement period

The procedure ends without action if no settlement is available.

Outstanding Balance

For the calculation of the outstanding balance, the function module BCA_MAP_BALANCE_VAL_GET is used. The module includes all transactions where posting date and value date match the end of previous period. Hence any backdated transactions that are posted after the end of this period are not taken into consideration for the outstanding balance determination.

Repayment

For the consideration of repayments, the function module BCA_MAP_BALANCE_VAL_GET is used. The module considers all balance-relevant transactions whose value date is between start of current period and end of current period as well as a latest posting date of current posting date for transactions.

Since a prerequisite for an interest free settlement is a repayment within a defined number of days from the of end the previous period, the repayment amount valuated after this resulting date is checked against the outstanding balance.

If the full repayment is reached before the given date, this date will be considered as the repayment date. In case there is a transition from an interest-bearing period to an interest free period, the interest free zero condition starts from the repayment date.

Product Assistance for Card ManagementAccount Management P U B L I C 19

Finding Previous Zero Conditions

The end of day procedure checks for zero conditions within the previous period. The check is considered successful, if there is a zero condition with a valid to-date that matches the end of the previous period and has Reason Code 1 (Interest free) assigned.

First Period

In the account´s first period (the period before the first settlement took place) it is assumed that the customer will pay full and therefore a zero condition will be set. Accordingly, there will be no interest in the first period. Still, if the customer does not fully repay in the following period, the zero condition for the first period will be deleted and additional interest is charged.

Interest on Budget Accounts

Once an interest free condition is set, not all transactions will be considered interest free. In the mentioned customizing activity, a turnover class can be assigned that will be interest bearing in any case (e.g. cash transaction shall always attract interests.)

In addition, interest attracted from budget accounts will be posted independent from the interest free status of the credit card account.

Backdated Postings

If a backdated posting comes into the system, the solution will not re-execute the end of day procedure to change zero conditions. If the posting is a debit item, interests are attracted from its value date until the current posting date according to the individual zero conditions set in between.

An exception from this procedure are presentments, which explicitly trigger a reprocessing for all periods in between the presentment´s value date and the current posting date. In IMG, define the transaction types which shall trigger an outdated reprocessing in Financial Services → Account Management → Credit Card Management → Settlement → Define Transaction Types for Reprocessing.

The reprocessing of old periods will not be triggered during posting of an item, but during the next regular end of day procedure. The procedure will check all items, that are posted during the current period, but with a value date in a previous period and of a maintained transaction type. Then all relevant periods are re-calculated, but the identified payment item is added to the outstanding balance.


Account Management

Settlement

Standard settlement procedure will consider "cash" turnover if customer calculation bases are used in financial conditions.

Main principles of calculations:

● Order of repayments consideration is described in chapter "Order of amounts that are repaid"● Granularity of calculations is one day. It means that provided functionality is not intended to be used with

intraday settlement● Customer function works only based on value dates● Changes of "Interest Calculation Period" parameter for account are not considered for previous periods● "Cash" turnover should be always debit● All credit transactions are considered as repayments● If an account has credit balance, no cash interest will be accrued● Settlement sequence which is described in chapter "Process chain..." should be considered● Overdraft limit BCA010 is considered

Process Chain Including Interest Free, Settlement, Amount Due and Budget Accounts

When executing the end of day procedure for interest free determination it is required to stick to a certain order with respect to other end of day procedures.

Since the standard settlement run shall already consider interest free conditions, it is required that the execution of the interest free end-of-day procedure (EoD) is performed before the actual settlement run.

As mentioned before, one of the first steps within the EoD is to retrieve the last period end which is the last settlement date. This is the date the outstanding amount is calculated for. In order to determine interest on budget accounts as well as instalments, make sure that the EoD for budget repayments was executed for the previous period.

Next step as part of interest free processing is to check whether the repayment has been done completely or not. Since the customer is given a defined number of days after the period end, until he can fully replay his outstanding amount, it is required that the interest free EoD is executed after this date (=payment due date). If the repayment is handled automatically using standing order (for further details check the chapter on Amount Due), you need to make sure that the interest free EoD is executed after the standing order processing date.

A working order of all processes could be:

Date Action

28.02.2017 End of old settlement period. Calculate outstanding amount.

01.03.2017 Start of new settlement period

01.03.2017 – 25.03.2017 Potential time frame for repayments of outstanding amount; either manually by customer or using processing of standing order


Date Action

26.03. 2017 – 31.03.2017 Potential time frame for interest free EoD. Zero conditions are set/removed.

31.03.2017 End of settlement period. Execute settlement for account considering zero conditions.

01.03.2017 – 31.03.2017 Potential time frame for budget account closure EoD and budget account repayment EoD

Order of Amounts that are Repaid

After the interest free EoD was executed, the settlement run calculates interest based on the individual conditions set. Assuming there are different interest rates on cash transactions, non-cash transactions etc., the calculation base has to determine which of those transactions to reduce first by repayments. Therefore, credit repayments shall decrease debit amounts in the following order:

1. Transaction over limit2. Transactions always bearing interest (e.g. cash transactions)3. Transactions that are potentially interest free (e.g. non-cash transactions)

Account Closure

The solution does not support the automatic processing of the end of day procedure during account closure. Therefore, it is required to execute the procedure before executing the account closure order.

Usually the interest free procedure only processes accounts that are due for settlement. In order to process an account on any given date (e.g. because it shall be closed), the checkbox “Force Processing” must be selected on the procedure´s selection screen in the tab strip “Processing Options”.

The primary idea was to trigger the interest free processing logic directly within the execution phase of the closure order processing. For this purpose, the BTE 0BCA2012 (Account Closure EXECUTE) was implemented. Unfortunately, this BTE is called after the account has been settled. Hence any changes to the account´s conditions are considered as backdated changes. As an alternative, the BTE 0BCA2018 (Counter for Settlement) should be implemented. Though this BTE is executed before the account´s final settlement, it was not suitable for placing the interest free logic inside. Reason for that is a limitation in the settlement process which does not consider changes to the account´s conditions that are not committed yet. Therefore, all changes done in the BTE are withdrawn when the settlement is performed.

For this reason, the current solution requires a manual execution of the interest free EoD with the “Force Processing” flag set.


Account Management

4.2 Budget Accounts

4.2.1 Introduction

In some regions, users are offered the choice to buy on loan, that is, having a purchase directly transformed into an installment loan instead of a debit on the card account. The loan is linked to the card drawn for the purchase, and is paid off against the card account.

If not available at the time of purchase, banks may also offer their users the option to transfer a purchase into a loan post purchase. As well, a loan can be created out of an amount taken from any account at the bank. In both of these scenarios, the loan behaves in the same way as if selected at time of purchase.

The terms for these types of loans are Budget or Budget Account.

The Budget behavior is as follows:

● The loan's nominal value is derived from the source purchase or source amount.● The loan's term is taken from either the user selection at POS, or by an input given on explicit transfer. A

configuration restricts the terms allowed for Budget.● The loan's repayments consists of:

○ The installments, calculated as the loan's nominal divided by the term.○ The interest rate payments, calculated based on the outstanding value and the rates defined.○ Both parts of the repayment will appear as separate line items on the Budget and card account.

● The loan account is automatically closed when paid off.● It is possible to do early (partial) repayments using direct payments to the loan account.

4.2.2 Realization within the Solution

The installment loans are not realized within SAP Loans Management. Instead, a current account built in Deposits Management forms the basis of the loans. In general, the result is:

● A current account with a limit of the loan's nominal value● An initialization with a debit posting of the nominal value● An enhancement to carry the term● The usage of financial conditions to define the loan's interest rate● An enhancement which is calculating the installment repayments at loan initiation● Additional end-of-day procedures to process repayments and account closures


4.2.3 Creation Types

As per introduction, different options are available to create a Budget:

● On purchase using POS selection● After purchase using transfer of a posted item● At any point in time by transfer from a source account

4.2.3.1 Select on Purchase

Select at time of purchase typically happens at the Point Of Sale (POS) and an authorization request is used to inform about the buy on loan. A normal reservation is created on the card account but it is marked with a loan indicator.

The loan is then created only when the incoming payment (Base II) is received. The term is taken from the selection at POS. The loan's rate is taken from the product setting of the loan's product or, if set up, from individual conditions.

NoteIf due to any issue the solution does not receive the authorization request the loan is not created. In such a scenario, the Base II payment is posted against the card account. In such a case, there's still the option to transfer the payment to the loan at a later stage.

4.2.3.2 Transfer Card Payment

You can offer the option to transfer a posted payment to the loan using SAPGUI or service call xxx. The process takes a payment that posted to a specific card and links the resulting loan to the same card.

NoteIf transferring a payment from a settled period, impact ….

To initiate a transfer, call transaction /n/CRDBS/DM_BUD_PI_TR. The source and target card are the same, as source of the payment to transfer, and as target of the resulting loan. The payment properties define the Payment Item which is determines the loan's nominal value with a debit posting.


Account Management

Transfer Payment

On the screen, provide the Card Number and Suffix of the card the payment transfer was done on. In addition, input the Transaction Type the budget's afddasf should get assigned. Confirm with Execute (F8). The next screen displays the transactions available for a transfer.

Details

Select a line and continue with Transfer (Shift + F8). A popup will ask for the loan's term. Input the number of months and continue.

TP3

If successful, the Budget account will be created and linked to the card.

4.2.3.3 Transfer Balance

You transfer an amount from any source account into a Budget by running transaction /n/CRDBS/DM_BUD_BALTR.

You must input the source account to credit from the Budget account and provide the card to link against the Budget. The Budget's repayments will debit on the card's main account.

Specify the amount to credit to the source account. This amount is used as the Budget's nominal value. You also need to define the term of the loan.

Enter the Transaction Type to use for the payment into the Budget Account.

Then Execute (F8), and check if the program returns success.


4.2.4 Pay-Off

Loans are automatically paid off against the related card's primary account. The monthly payments consist, as per initial description, of two separate line items; one for the installment and one for the interest payments.

The monthly repayments are calculated and posted by a corresponding end-of-day procedure /CRDBS/BUDG_REPAYM . Plan this procedure for your daily processing.

With the automated repayments, the loan completely pays itself off by the end of its defined term. When the loan is paid off completely, it is automatically closed.

In addition to the automated repayment per repayment plan, a user may decide to do either partial or full unplanned repayments. A full repayment, paying off the loan completely, will lead to an automated closure of the loan.

A partial repayment does in contrast only reduce the outstanding amount. The loan will after a partial repayment continue with its pre-calculated repayment rates. However, it will most probably terminate earlier than planned. Should, due to the partial repayment, the final installment be less then the normal ones, this will be handled by the software.

If there is an overpayment it is credited to the card account with the loan closure.

4.2.5 Closure

Closure is triggered by program /CRDBS/DM_BUD_ACC_CLOSURE_EOD. For all accounts to process, it checks if the loan is fully paid off. If so, it marks the account for closure. The actual closure is then performed by program RBCA_OR_TOC_PP_START_BCA_BOTC.

/CRDBS/BUDG_CLOSURE


Account Management

5 Message Processing

5.1 Introduction

Card management processes authorizations and clearing and settlement of card transactions. This supports the following:

● Ability to follow up on individual authorizations and related decline reasons● Ability to check the status of the related clearing and settlement processing

Additional types of Visa messages are supported depending on the business scenario. The trigger of such messages is explained in the respective chapters. For details on the logging of such messages, see below.

5.2 Transaction Processing

5.2.1 Base I - Authorization Requests

Authorization requests are received in real-time and processed by card management. Both SAP Payment Engine and banking services from SAP are involved. SAP Payment Engine is connected to the payment network and converts the Base I message into an internal format and triggers the connected systems required for the processing. Within card management, banking services from SAP is called to perform material checks. This includes checks of card and card account status, available amount and limits. If the material checks are successful, banking services from SAP will create a reservation on the card account. In the processing, data and logs are generated on both SAP Payment Engine and banking services from SAP. Make use of this data to follow up on queries for specific authorization requests.

Payment Orders

For authorization requests, SAP Payment Engine (PE) creates an internal object called Payment Order.

The Payment Order holds mainly administrative and control data. Each Payment Order has at least one sibling, a Payment Item. The Payment Item holds transaction details like amounts and currencies, but also administrative and control data.

Product Assistance for Card ManagementMessage Processing P U B L I C 27

For an authorization request (Base I), SAP Payment Engine (PE) creates a Payment Order with one Payment Item attached. The Payment Item is then called Reservation Item, because only a reservation is created on the related card account.

To view Payment Orders, go to SAP Easy Access Menu → Payment Engine → Payment Order Management → Edit Payment Orders (Expert).

To view Payment Items, go to SAP Easy Access Menu, select Payment Engine → Information System → Overview: Payment Items.

How to Find a Payment Order for a Specific Card

You will not be able to select a Payment Order based on card credentials like PAN. The reason is that Payment Engine is not storing the unencrypted PAN. The best alternative is a selection based on the account the card is linked to.

Should you not know the account number, log on to SAP Banking Services (BaS) to get hold of the account number. Then return to Payment Engine. However, a selection of Payment Order for a specific account is also not supported. Instead, find Payment Items on the account in program Overview: Payment Items. For identified Payment Items, a link to the parent Payment Order is found.

Display Message Content (XML)

The solution offers a program to view incoming and outgoing Base I message content. The program will display the data exchanged in XML format. To display the data, go to SAP Easy Access Menu → Payment Engine → Credit Card Management → Display Base I Message Content or call transaction /CRDPE/XML_DISP. You'll be prompted for the details of the message to display.

If the Business Object Date and Number are not known, find the message of interest in the display of Payment Orders or Request Agents. Note down date and number of the business objects to input into the program Display Base I Message.


Message Processing

5.2.1.1 Purchase with Cash Back

For a purchase with cashback, card management receives both the overall amount and the cashback portion. The Payment Engine reflects the details as follows:

● The Payment Order shows the overall amount in field Total Amount● The Payment Items shows the amount of the purchase● In the Remittance tab of the Payment Item, find the Cashback Amount

5.2.2 Base II Clearing and Settlement

Base II data is received in files that are imported into Payment Engine for processing.

To view results of the clearing and settlement process, use Payment Engine's display of payment orders. For postings, a payment order is created per financial record and two payment items are assigned: Originator and Recipient Payment Item.

Card management tries to match each Base II record of a client's financial transaction with a corresponding Base I authorization request. If a match is successful, the status for the Prenote on banking services from SAP changes to Assigned.

The matching logic is based on comparison of the following fields:

Field Name Base I Base II

Transaction Date Field 13 TCR 0 position 58-61

Acquiring Institution Identification Code Field 32 TCR 0 position 28-33

Authorization Code Field 38 TCR 0 position 152-157

Transaction ID Field 62.2 TRC 5 position 5-19

Transaction Amount Field 4 TCR 0 position 77-88

Card GUID - (Representation of PAN) - (Representation of PAN)

The matching logic first tries to match following fields:

● Match Transaction Date, Acquiring Institution Identification Code, Authorization Code, Transaction ID and Card GUID

● If not successful, the logic continues with a different set of fields. The following list gives the priorities of fields used for a matching, where each new set is only used if the previous set failed to match:○ Match Acquiring Institution Identification Code, Authorization Code, Transaction ID and Card GUID○ Match Acquiring Institution Identification Code, Authorization Code and Card GUID○ Match Acquiring Institution Identification Code, Transaction ID and Card GUID○ Match Transaction Date, Acquiring Institution Identification Code, Transaction Amount and Card GUID

Product Assistance for Card ManagementMessage Processing P U B L I C 29

5.3 Further Visa Messages

For messages without financial impact, SAP Payment Engine does not generate Payment Orders or Payment Items. Instead, a Request Agent is created. This applies to following types of messages that card management processes:

● Base I○ Balance Inquiry○ Account Verification Request○ Reversals○ Visa File Maintenance Requests○ Token Lifecycle Management

● Base II○ Dispute status - TC 33Disputes [page 42]○ Fraud Reporting - TC40Fraud Reporting System [page 40]○ Fees & Charges - TC46

5.3.1 Balance Inquiry

A specific type of authorization request is received for balance inquiries. In contrast to payment related messages, no reservation handling is required. Because of that, the Payment Engine does not log a balance inquiry with a payment order. Instead, each balance inquiry creates a request agent.

NoteA response to a balance inquiry is only provided for the primary card holder, who is also the account holder of the account balance requested. Should any other card holder place a balance inquiry, a balance value is not returned but instead a response code xxxx.


Message Processing

6 Visa File Maintenance Requests

6.1 Introduction

Some Visa services are supported by files for which participating issuers may populate the individual records. Among these files, the solution supports a data exchange for the following formats:

● Preauthorized Payment Cancellation Service (PPCS)○ Portfolio File

● Positive Cardholder Authorization Service (PCAS).○ PIN Verification File○ Exception File

The file records are exchanged using File Maintenance Requests. Technically, from an issuer's perspective, these are outgoing Base I messages of type 0302. The requests may comprise update and inquiry operations. The details of the operations supported by the solution are described in the following sections.


The requests are logged in the Payment Engine.

Requests in Payment Engine

Product Assistance for Card ManagementVisa File Maintenance Requests P U B L I C 31

Visa supports the following operations on File Maintenance Requests:

● Add● Change● Delete● Replace● Inquire

The next sections describe the processing of requests and related operations. If an operation is not listed, it is not supported by the solution.

6.2.1 Preauthorized Payment Cancellation Service

This functionality enables participating issuers to stop payments on preauthorized transactions for recurring payments. Technically, this is done with a file maintenance request to Visa, where the File Name is set to PF (Portfolio File). The message triggers an action for records in the Portfolio File in Visa's Cardholder Database. The card management user interface triggers requests with an action code of Add, Delete, Replace, or Inquire.

Call transaction code /CRDBS/DM_RECURR_TR or go to SAP Easy Access Menu --> Financial Services -> Account Management -> Credit Card Management -> Portfolio File Management to manage Portfolio File records.

Here is an example of the selection screen:

Portfolio File Management

The following screen shows a list of payments for the card provided. Depending on the initial selection, only recurring payments or all payments on the card within the given time frame appear.

Recurring Transactions

NoteOnly posted payments (payment items) are eligible to trigger a stop-order. Reservations (prenotes) are therefore not displayed.


Visa File Maintenance Requests

6.2.1.1 Add

You add records to the Portfolio File by selecting a transaction and choosing Add from the toolbar. A new screen appears which offers all input variations supported by Visa. For details on the different options, please refer to the Visa specifications.

Create Stop Order

Card management prefills some details from the transaction selected in the previous step. If needed, you can overwrite these values by unchecking Data from transaction.

The Expiration Date defaults to 31.12.9999.

Confirm the input with Submit.

6.2.1.2 Inquiry

You can inquire records with Visa by selecting a transaction and choosing Stop-Orders. A list of the available Stop-Orders displays.


Stop Orders Inquiry

Select a Stop-Order and choose Inquiry (Shift + F1) and you will be prompted for the type of record to place the inquiry.

Stop-Order Type

Submit to view the details of the Stop-Orderas the data is retreived online from Visa.

Payment Item Details



From this screen, you may Change or Delete a record.

6.2.1.3 Change

To change/replace a record, from the inquiry screen, select Change. Enter your changes and Submit to update the data to Visa.

6.2.1.4 Delete

To remove a record from the Portfolio File, select Delete.

6.2.2 Positive Cardholder Authorization Service (PCAS)

Positive Cardholder Authorization Services (PCAS) provide instructions to Visa that are used to decide about the approval, decline or referral of authorization requests for Stand-In Processing (STIP). Among other services, PCAS checks cards against two files; the PIN Verification File and the Exception File.

6.2.2.1 PIN Verification File

Visa verifies PINs by checking them against the PIN Verification File for issuers that participate in the PIN Verification Service. The file contains the PIN Verification Values (PVV) and PIN Verification Key Indexes (PVKI) Visa requires to perform the verifications.

Card management updates Visa PVV as follows:

● Automated on card creation (Add)The card creation confirmation received from an external system includes the PVV to send to Visa. The card creation includes both issuance of a new card and replacement or renewal cards.

● Automated on PIN change (Change)The new PVV is retrieved from an external system which maintains PINs.

● ManualAn explicit trigger by an external system provides the PVV to update Visa.


6.2.2.1.1 Add

The prerequisite for the automated PVV update to Visa is an external system for card creation is connected to card management. The external system sends the PVV and PVKI associated with the card upon confirmation of card creation. There is no manual intervention for this process.

The related file maintenance request is sent with File Name P2 (PIN Verification File) and the File Update Code is set to 1 (Add) for the card creation.

Alternatively, trigger service xxx.

6.2.2.1.2 Change

For a PIN change, the PIN management system sends the new PVV to card management using a service call. The prerequisite is that a PIN management system is connected and similar to card creation there is no manual intervention.

Card management instantly sends the new details to Visa using a File Maintenance request of Type P2 and File Update Code 2 (Change). Or update (4)???

Alternatively, trigger service xxx.

6.2.2.1.3 Delete

To delete a PIN, manually trigger service xxx.

6.2.2.2 Exception File

The Exception file contains information on cardholder accounts that require non-standard responses to authorization requests. The supported responses (defined as Action Codes) are:

● 01 Refer to card issuer● 04 Pickup card● 05 Do not honor● 07 Pickup card, special condition● 11 Approval for VIP● 14 Invalid/closed account● 41 Lost card, pickup● 43 Stolen card, pickup● 54 Expired card



Visa supports four fields to set in the Exception File records, of which card management only supports Action Code (field 127E.1) and Region Coding (field 127E.2). Not supported are Cardholder Spending Amount Limit (127E.3) and Cardholder Spending Count Limit (127E.4).

NoteCard management sends Exception File updates with a Region Coding of 0. With that, the card is present in the National Card Recovery File (NCRF) but not in Regional Card Recovery File (RCRF).

Maintenance of the Exception File happens either automatically or based on a manual trigger. The automatic maintenance is based on the pre-defined handling of card locks. For relevant card locks, you define that the system updates the Exception File in sync with the lock status of a card.

A manual trigger is also supported for the card maintenance.

The automated and manual syncs have a mutual impact as the most recent change always defines the records at Visa. You can overwrite an automated Add by manually removing the Action Code from a card. Likewise, a manually set Action Code is removed by an automated Delete when triggered by a lock removal.

6.2.2.2.1 Add

Exception File updates are sent as file maintenance requests of File Type E2. When adding a record at Visa, the File Update Code is set to 1 (Add).

Triggers to add a record are either based on a PLM document or a manual assignment.

6.2.2.2.2 Delete

As for adding a record, the deletion of a record is either triggered by a lock-based rule or manually. For locks, if a PLM document is set to Inactive or Closed, a related entry in the Exception File will be revoked by card management.

Alternatively, remove the Action Code on the card to manually trigger the deletion of a record.


7 Additional Services

7.1 Emergency Cash

For emergency cash, create a reservation on a card account using service BankAccountContractProcessingManageBankAccountPrenoteEntryIn_V1 and operation CreateBankAccountPrenoteEntry. The service will return an Authorization Code within the Payment Notes section of the response.

Use the Authorization Code for the emergency cash forms exchanged with Visa.

NoteWhen the financial transactions related to emergency cash come in via Base II, an automated matching of a financial transaction to the reservation created manually is not supported.

7.2 Force Next Transaction Online

It is possible to force a card to get online for the next transaction. This is realized by a script sent to the card chip. The delivery of a script does require the card holder to swipe the card at an ATM. The following card usage at a terminal will force the card to go online, assuming the terminal is not an offline terminal.

To trigger the process, execute SAP Easy Access Menu → Financial Services → Account Management → credit card management → Card Transactions → Force Next Transaction Online or call transaction /n/CRDBS/NEXT_TR_ONLS. Provide the credentials of the card to force online and Execute (F8). This initiates a request to a Chip Management solution to deliver a script with the next in-coming ATM transaction.

NoteThis feature does only work if card management is connected to a chip management solution that takes care of EMV validation and scripts

Product Assistance for Card ManagementAdditional Services P U B L I C 39

7.3 Fraud Reporting System

The Fraud Reporting System (FRS) is Visa’s centralized clearinghouse that helps users report, track, and analyze fraudulent transactions. The service consolidates fraud information, helps users detect fraud patterns, and reduces losses due to fraud.

The VisaNet network reports fraudulent transactions and consolidates the information into status and performance reports on a daily, weekly, monthly, or quarterly basis. These reports enable users to verify their submitted transactions, correct and resubmit rejected transactions, and accurately track any fraudulant activity.

Users must report all fraudulant transactions to Visa no later than 60 days after detection. Users may report using either VROL or Fraud Advice Reporting. Card management supports the Fraud Advice Reporting which allow users to maintain relevant information. The relevant information is then generated and submitted to Visa. This is realized with client-generated Transaction Code (TC) 40 as part of the Base II format.

7.3.1 Overview

Find the program, Mark Fraudulent and Dispute Transactions, in SAP Easy Access → Financial Services → Account Management → Credit Card Management → Card Transactions or call transaction /CRDBS/MARK_PAYM_IT that handles all actions related to Fraud Reporting. Mandatory inputs are the credentials of the card account for which to display transactions. You may restrict the hitlist with further parameters, including to only display transactions already in a fraud or dispute state.

When done with the selection criteria, confirm with Execute or F8 to navigate to the result list.


Additional Services

7.3.2 Report Fraud

Select the transaction to report and choose a related status with button Set Fraud Type. Save your changes.

Mark Fraud and Disputes

This will mark the related transaction with the selected status. However, it does not trigger an update to Visa.

The update to Visa is done via Base II with an issuer-generated TC 40. The TC 40 is generated on and sent to Visa by Payment Engine. The TC 40 generation is done in program /CRDPE/PE_FRAUD_REPORT.

RecommendationConsider setting up a daily scheduled execution of above program. With that, all updates of a day on fraud will be sent to Visa.

You may also manually trigger an update by calling the program with transaction /CRDPE/FRD_REP.

7.3.3 Receive Updates

You may receive Transaction Response Records from Visa if you returned the report options signup form and selected electronic responses.

Visa returns information to the issuer using Visa-Generated TC 40 records. Card management receives the TC 40 records within the Base II files. When processing the Base II records, the TC 40 data is imported as well. The records update the transaction details within the solution.

In program Mark Fraudulent and Dispute Transactions, you will also find the Fraud Type received from Visa, enriched with a timestamp of the incoming Visa update.

Product Assistance for Card ManagementAdditional Services P U B L I C 41

7.4 Disputes

Card management does not offer tools to automatically claim disputes at the payment network. Supported are following functionalities:

● Mark payments that were claimed as dispute using online tools like VROL● Update payment items with a dispute status received from Visa using TC 33

7.4.1 Overview

To view dispute related information, call program Mark Fraudulent and Dispute Transactions. Find the program in SAP Easy Access → Financial Services → Account Management → Credit Card Management → Card Transactions or call transaction /CRDBS/MARK_PAYM_IT. It is the same program as for handling fraudulent transactions.

7.4.2 Mark Dispute

Select the transaction to mark and choose a related status with button Set Dispute Status. Save your changes. The transaction will be updated with the status set.

NoteThis is just an informative status kept in card management. No update at Visa takes place.

7.4.3 Receive Updates

Updates from Visa are received with the Base II records in TC 33. With the import and processing of Base II files, the related information will automatically be processed. On SAP Payment Engine, a Request Agent is created per record. On banking services from SAP, the transaction in dispute will receive a corresponding update. Both the Dispute Status and the Dispute Financial Reason Code will be set as per Visa input.

View the Reason Code in program Mark Fraudulent and Dispute Transactions.


Additional Services

8 Token Lifecycle Management

8.1 Introduction

Card management supports the processing of token requests and token-based transactions. The tokens must originate from VTS (Visa Token Services). It also keeps a record of all tokens issued on its own cards and allows for triggering token status changes


In normal operation, card management holds all tokens with their respective statuses based on the input received from Visa. Card management takes the information received and updates its own records. The details shown in the token view are based on that information.

Users can trigger a status change for any token which is created and not yet deleted from card management. The status changes only when the related Visa message is received.

8.2.1 Token Enrollment

Token enrollment involves a sequence of the following steps:

● Token Activation Request (optional)● Token Creation Advice● Token Activation Advice (optional))

Card management mainly consumes messages related to token enrollment. Based on the incoming messages, it maintains token records in its own token storage. It sets the token status as per the incoming messages.

Only during the Token Activation Request (TAR), does card management play an active role. Processing a TAR involves checking the card and card account status. For some types of tokens, it returns a response code to trigger a step-up authentication. For some token types it does not even trigger a TAR, such as when the issuer already has control using its own app.

The following token types are known by Visa:

● 01 - eCOM/COF (e-Commerce/Card On File); used for e-commerce transactions. Can only be used for non-proximity transactions.

Product Assistance for Card ManagementToken Lifecycle Management P U B L I C 43

● 02 - SE (Secure Element); can only be used for proximity transactions.● 03 - CBP (Cloud-Based Payment); assigned to HCE-based wallet providers. Can only be used for proximity

transactions.● 05 - E-commerce enabler; assigned to aggregators like Visa Checkout, which support multiple e-

commerce merchants.● 06 - Pseudo account

Step-up is supported for HCE 3rd Party Wallets and SE. For both, if the status checks are successful, card management responds with the code to request a step-up. For step-up, Visa initially creates inactive tokens that are activated after successful step-up. For other cases, tokens are created as active right away.

8.2.2 Token Management

Records for all tokens created are maintained in card management's storage. This gives the user the option to directly access token-related information and to trigger certain token status changes without the need to log-in to Visa.

8.2.2.1 View Token

Go to SAP Easy Access Menu → Financial Services → Account Management → credit card management → Token Management → Token Management or call transaction /n/CRDBS/TOK01 to view all tokens issued for a card. You will receive a prompt for Card Type and Card Number to identify the card to display all tokens.

To view all token issued for a card, ransaction /CRDBS/TOK01. You'll be prompted to provide card type and card number to identify the card for which to display all token. On the next screen, a list of tokens associated to the card input is displayed.

Token Management for Card

8.2.2.2 Change Token Status

From within the display of tokens, the following status changes are triggered:

● Activate● Delete● Suspend● Resume


Token Lifecycle Management

The supported status changes depend on the current status of the token. To change the status of a token, press the related button.

When saved, a Base I message of Type 06xx generates. The message holds all the details of the token status change and updates Visa. This all happens as online processing.

When saved, the solution generates a Base I message of Type 0302. The message holds all the details of the token status change and updates Visa. This all happens as an online process. Visa responds to the 0302 message to indicate success or failure of the operation. Only upon success does card management update the status of the token in its own database.

8.2.2.3 Access Using Service

The service, BankCardContractProcessingManageBankCardContractIn receives token information and then retrieves and updates the card details.

NoteCall operation UpdateBankCardContract to update a token status. Make sure to keep the flag suppressTokenChangeForwardToExternalSystemIndicator unset in the call. Otherwise, no update to Visa takes place and only a local change is done.

Product Assistance for Card ManagementToken Lifecycle Management P U B L I C 45

9 Triggers for Notifications

Notifications are useful to inform customers as well as bank staff about business events. Card management does not include a component to send messages like SMS. Instead, certain triggers are included that can be used to connect to a messaging system.

SAP Payment Engine

For SAP Payment Engine, card management offers triggers available for following events:

● Authorization approved● Authorization declined● Authorization advice received where Visa declined● PIN change, when a confirmation is received from the chip & script management component that a PIN

change script was successfully delivered to the card● 2nd presentment processed● Balance Inquiry received

The triggers are provided with BAdI /CRDPE/PE_BADI_NOTIFICATIONS. To implement, refer to IMG Payment Engine → Credit Card Management → BAdI → Triggers to Notify Customers.

Banking Services from SAP

On banking services from SAP, card management offers triggers for the following events:

● Card produced● Limit changed● Account product change● Card product change● Authorization decline on merchant category restriction● Card lock/unlock● Account closure● PIN change, when the PIN replacement process was triggered● Transaction marked as fraud● Card renewal performed● Card closure● Token change● Limit utilization changed● Bank statement generated● Card delivered


Triggers for Notifications

To process the events, implement BAdI /CRDBS/BS_BADI_NOTIFICATIONS using IMG Financial Services → Account Management → Credit Card Management → BAdI → Triggers to Notify Customers.

Product Assistance for Card ManagementTriggers for Notifications P U B L I C 47

Important Disclaimers and Legal Information

HyperlinksSome links are classified by an icon and/or a mouseover text. These links provide additional information.About the icons:

● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your agreements with SAP) to this:

● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any

damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.

● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this information.

Beta and Other Experimental FeaturesExperimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use the experimental features in a live operating environment or with data that has not been sufficiently backed up.The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.

Example CodeAny software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of example code unless damages have been caused by SAP's gross negligence or willful misconduct.

Gender-Related LanguageWe try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.


Important Disclaimers and Legal Information

Product Assistance for Card ManagementImportant Disclaimers and Legal Information P U B L I C 49

www.sap.com/contactsap

© 2019 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. The information contained herein may be changed without prior notice.

Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies.

Please see https://www.sap.com/about/legal/trademark.html for additional trademark information and notices.

THE BEST RUN

https://www.sap.com/about/legal/trademark.html