NI Functionality – API

5/11/2014
1 API – Introduction
API (Application Programming Interface) is the middleware between NI Card Management System and
TIBCO providing Credit Card Information from NI Card Management System back to various interfaces
and external third party systems via TIBCO. API communicates through request and response messages
using TCP connection.

Data Queue: Data queue is being used to log the request & response message. Incoming data queue is
populated by TIBCO system whereas outgoing data queue is populated by NI Card Management System.
Incoming message is forwarded to API processor, which is linked to respective API service based on
message type. The API service performs the necessary functional processing associated with it and
returns the response back to API Processor which in turn writes the response message back to Outgoing
Data Queue.
API Listener: API listener Acts as a server which constantly tries to listens or wait for any request
message arriving on the incoming Data Queue from TIBCO end & forwards the retrieved message to API
Processor.
API processor: API processer receives message from Listener and validates below mandatory checks on
header information:
 API system parameter should not indicate API SYSTEM UNVAVAILABLE.
 If NI Card Management System is in batch mode then the maintenance indicator should not be
switched ON. (API System will be in Inquiry Mode due to maintenance activity happening in NI
Card Management System database during EOD batch)
 API Service should be switched ON at System, bank or product Level
1.1 API Services
Various API services are available in NI system which can be activated at product level. The valid values
for the flags are:

a) N = Not Active for the product

b) Y = Active for the product

1.1.1 Credit Card Payment

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N N N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N N N Y Y Y Y Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y Y

AUB/BBY/DF/FGB/FGI/EIB/ENBD haves a credit card payment service to post payment to the accounts
through various channels using valid card number. Below operations are performed as part of credit
card payment service:

AUB:
 Memo credit at account level is directly updated by adding the payment amount.
 The number of memo credits is increased by one.
 Memo debit at account level is directly updated by adding the payment reversal amount.
 The number of memo debit is increased by one.
 Payment record file is updated after doing TIBCO payment which is fed as input into the EOD
batch.
 Payment log file is updated after doing TIBCO payment. Report gets generated for the same.

BBY/DF/FGB/FGI/EIB/ENBD
 Memo credit at account level is directly updated by adding the payment amount.
 The number of memo credits is increased by one.
 Payment record file is getting updated after doing TIBCO payment which will be feed into the
batch.
  Payment log file is getting updated after doing TIBCO payment. Report gets generated for the
same.
 Refer to the 1.2 Reports and extracts for request & response message layout & report layout.
Refer to the 1.2 Reports and extracts for further information on the file & report layouts.

1.1.2 Status Change

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N Y N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N Y N Y Y Y Y Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y N

AUB and /NBF/BBY/DF/FGB/FGI/QIIB/ENBD have a status change service to activate a card, block a card
or update the pin offset. These services are selected based on the TYPE (sub service) provided by TIBCO
which is specified as follows:
Type :

ACT – card activation

BLK - Card block
PCH – PIN offset update

1.1.2.1 Card Activation

 Type (received from TIBCO) should be given as ‘ACT’ to activate the card
 Account level (Primary card) block code is removed in case of split setup
 Card level (Primary & supplementary) block code is removed in case of combined setup
 Current card expiry flag is reset to ‘N’.
 Previous card expiry flag is reset tot ‘Y’.
 Monthly fee charge waive flag is set to levy.
 Pin offset file is updated for existing record.
 Monetary log file is updated which will be fed as input to the batch to generate maintenance
report after VisionPLUS End Of Day process.
Note: The Split Account Setup establishes the customer at the top of the hierarchy. Customer can be
associated with multiple accounts. Each account under the customer can be linked with only one card
(primary or supplementary).
1.1.2.2 Card Block
 Type (received from TIBCO) should be provided as ‘BLK’ to block a card
 The input block code is validated and its priority is checked against the existing block code.
 If the block code is valid and has a higher priority than the existing block code, it is applied on
the account/card based on the card scheme.
 Apply at account level block code in case of split setup
 Apply at Card level block code in case of combined setup
 Financial authorization system (FAS) special handling file should be updated if the block applied
is for a lost card or fraud.
 Log file is updated which is fed as input to the batch to generate maintenance report after
VisionPLUS End Of Day process.

1.1.2.3 Pin Update

 Type should be ‘PCH’ and pin offset value should be provided to update the pin.
 The pin offset is updated in the system.
 TIBCO request detail file for Dubai First Bank (026) is getting updated to extract details of cash
pin change done on current processing date to generate cash pin change letter.
 Refer to the 1.2 Reports and extracts for request & response message layout & TIBCO request
detail file layout

1.1.3 Card Maintenance

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N N N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N N N N Y Y Y Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y Y

AUB/DF/FGI/FGB/QIIB/ENBD/EIB has a card maintenance service to update or modify the

Insurance/Address/Direct Debit/Demographic details.
These services are selected based on the TYPE (sub service) provided by TIBCO which is specified as
follows:
Type:

INS – Insurance Maintenance

ADR – Address Maintenance
DDB – Direct Debit Maintenance
DMG – Demographic Maintenance

1.1.3.1 Insurance Maintenance

 Valid card number should be provided in the incoming message.
 Valid Insurance product should be provided in the incoming message.
 Action should be ‘E’ or ‘D’ or ‘R’.
 E – Start
 D – Cancel
 R – Reinstate
 The Account should bein active, dormant or new status.
 The insurance product should not be active if the action is ‘E’ or ‘R’.
 The insurance product should be active if the action is ‘D’.
 The Insurance product is activated, cancelled or reinstated based on the action.
 A record is written in the log file. This log file is processed in the EOD batch to generate the
maintenance reports.
 Refer to the 1.2 Reports and extracts for request & response message layout.
 The data that is updated can be seen in the Layout attached in the 1.2 Reports and extracts

1.1.3.2 Address Maintenance

 Address can be maintained based on the card number or the CIF ID.
 If CIF is provided, all the cards tagged with the provided CIF are updated.
 If card number is provided, then only the card provided is updated.
 AUB does not have CIF concept, hence only card number is provided for AUB.
 Currently 51 fields related to address can be updated.
 The Byte field in the incoming message determines which fields have to be updated.
 If the 5th & 10th fields in the layout have to be updated, then the 5 th & 10th bytes in the Byte field
should be one and the rest of the bytes zeros.
 A record is written in the log file. This log file is processed in the EOD batch to generate the
maintenance reports.
 The data that can be updated can be seen in the Layout attached in the 1.2 Reports and extracts

1.1.3.3 Direct Debit Maintenance

 Valid Card number should be provided in the incoming message.
 Action type can be ‘A’ or ‘D’ or ‘U’
 A – Activate
 D – Deactivate
 U – Update
 The Account should be in active, dormant or new status.
 DD Account Number should be provided if action type is ‘A’.
 The Direct Debit is activated, deactivated or updated based on the Action Type provided in the
incoming message.
 A record is written in the log file. This log file is processed in the EOD batch to generate the
maintenance reports.
 The data that is updated can be seen in the Layout attached in the 1.2 Reports and extracts
1.1.3.4 Demographic Maintenance
 Demographic Details can be maintained based on the card number or the CIF ID.
 If CIF is provided, all the cards tagged with the provided CIF are updated.
 If card number is provided, then only the card provided is updated.
 What should be the action type?
 <<Attra>>: There is no action type for Demographic maintenance. Fields are getting updated
based on incoming byte field provided by TIBCO team.
 AUB does not have CIF concept, hence only card number is provided for AUB.
 Currently 30 fields related to Demographic details can be updated.
 The Byte field in the incoming message determines which fields have to be updated.
 If the 5th & 10th fields in the layout have to be updated, then the 5 th & 10th bytes in the Byte field
should be one and the rest of the bytes zeros.
 A record is written in the log file. This log file is processed in the EOD batch to generate the
maintenance reports.
 The data that can be updated can be seen in the Layout attached in the 1.2 Reports and extracts

Note : Currently AUB is not using the CIF ID Concept. Therfore maintenance can be carried out using
the card number only.

1.1.4 Customer Card List

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N N N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N N N N Y N N Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y N

 The customer card list can be extracted based on the Card Number or the CIF ID.
 If CIF is provided, all the details of all the cards tagged with the provided CIF are extracted.
 If Card Number is provided with Type as ‘A’ (Account), the details for all the cards under that
account are extracted.Explain the valid values for type.
 If Card Number is provided with Type as ‘C’(Card), the details for that particular card are
extracted.
 AUB does not have CIF concept, hence only card number is provided for AUB.
 The maximum number of cards under an account, that can be extracted at one time is 10.
 The data that will be extracted for each card can be seen in the Layout attached in the 1.2
Reports and extracts
1.1.5 Customer Card Details
AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N Y N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N Y N N Y Y Y Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y N

 The customer details can be extracted based on the Type field received in the incoming
message.
 Valid Card Number should be provided in the incoming message.
 The valid values for the Type parameter are
 CDO (Embosser details including transaction details and statement details)
 DNA (Customer name address details)
 DAD (Customer demographic details)
 DAE (Customer AQU Extract details)
 The data that will be extracted for each Type can be seen in the Layout attached in the 1.2
Reports and extracts

1.1.6 Card Balance Inquiry

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N Y N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N Y N Y Y Y Y Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y Y
  Valid Card Number should be provided in the incoming message.
 For Split account setup, the account level credit limit is considered for OTB calculation.
 For Combined account setup, the account level credit limit is considered for OTB calculation.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.1.7 Statement Inquiry

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N Y N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N Y N N Y Y Y Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y Y

In this service we can either extract the Statement header or Detailed Statement. The transaction details
are provided in Detailed Statement.

1.1.7.1 Statement Header Inquiry

 Type should be provided as ‘H’ in the incoming message.
 Valid Card Number should be provided in the incoming message.
 The incoming message can have the complete date (Statement Date), only month & year
(Custom Date) or no date.
 If the Statement date is provided, the data for that statement is extracted if it is available.
 If Custom date is provided, the data for the statement of that month & year is extracted if it is
available.
 If no date is provided the data for a maximum of 18 statements for the account can be extracted
at a time if available.
 Only Account & Plan( logical group of transactions for e.g. Retail/Cash) details are extracted
 The transaction details are not extracted.
 The number of transactions, transaction pointer, sort order and scroll type are not be provided
in the incoming message for Statement Header inquiry.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.1.7.2 Statement Detail Inquiry

 Type should be provided as ‘F’.
  Valid Card Number should be provided in the incoming message.
 Sort order should ‘A’ or ‘D’
 A – Ascending
 D - Descending
 The incoming message can have the complete date (Statement Date), only month & year
(Custom Date).
 If the Statement date is provided, the data for that statement is extracted if it is available.
 If Custom date is provided, the data for the statement of that month & year is extracted if it is
available.
 Account & Plan details are extracted.
 The transaction details are also extracted.
 The details of a maximum of 98 transactions can be extracted at a time.
 The transaction pointer determines the first eligible transaction from where the extraction
begins. The default number of transactions that can be fetched at one time is 20.For example if
we have extracted 20 transactions by giving Pointer as 1 (First 20) in the first request, we should
give the pointer as 21 to extract the next 20 transactions in the subsequent request.
 IPP (Installment Payment Plan) details are extracted for ENBD/EIB.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.1.8 Card Authorized Transactions

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N Y N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N Y N N N N N Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y Y

 The Authorized Transactions can be extracted for the account or card based on Type.
 A – Account
 C - Card
 Valid Card Number should be provided in the incoming message.
 The transactions can be sorted in ascending or descending order based on Sort Order.
 A – Ascending
 D - Descending
  The number of transactions to be extracted is provided in the incoming message.( Transaction
authorized prior to the EOD batch is not currently part of this message).
 A maximum of 98 transactions can be extracted at a time.
 A date range can be given to filter the transactions based on effective date.
 If a date range is not provided, all the transactions for the account/card irrespective of the
effective date are extracted.
 The transaction pointer determines the first eligible transaction from where the extraction
begins. The default number of transactions that can be fetched at one time is 20. For example if
we have extracted 20 transactions by giving Pointer as 1 (First 20) in the first request, we should
give the pointer as 21 to extract the next 20 transactions in the subsequent request.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.1.9 Posted Transactions

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N Y N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N Y N N Y Y Y Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y Y

 The Cycle to Date Posted Transactions or all the Posted Transactions can be extracted for the
account based on Type field provided in the incoming message.
 A – All
 C - Cycle
 Valid Card Number should be provided in the incoming message.
 The transactions can be sorted in ascending or descending order based on Sort Order.
 A – Ascending
 D - Descending
 The number of transactions to be extracted can be provided.
 A maximum of 98 transactions can be extracted at a time.
 A date range can be given filter the transactions based on effective date.
 If a date range is not provided, all the transactions for the account/card irrespective of the
effective date are extracted.
 The transaction pointer determines the first eligible transaction from where the extraction
begins. For example if we have extracted 20 transactions by giving Pointer as 1 (First 20) in the
first request, we should give the pointer as 21 to extract the next 20 transactions in the
subsequent request.
  IPP (Installment Payment Plan) details are extracted for ENBD/EIB.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.1.10Status Inquiry
AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N N N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N N N Y Y Y Y Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y N

 Valid Card number should be provided in the incoming message.

 If the account setup for the card provided is Split, the account level block code is extracted.
 If the account setup for the card provided is combined, the card level block code is extracted.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.1.11 Merchant Details

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N N N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N N N N N N N N

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

N N N N N N

 This service can be used to extract the merchant details based on the merchant id.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts
1.1.12 Supplemental Card Limit Change
AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N N N

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N N N N N N N N

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

N Y Y Y Y N

 This service can be used to update the card limit for supplementary cards.
 The UPT-IND field in the incoming message should be spaces.
 The card limit provided should be less than the account level credit limit.
 A record is written in the log file. This log file is processed in the EOD batch to generate the
maintenance reports.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.1.13 IPP booking through API

AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

N N N N N N N N N N N

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y Y

 IPP can be booked through API provided the IPP booking service should be set as active in API
parameter screen.
 Following validations are performed on the incoming request for booking the IPP.
 The card/Account number exists in the VisionPLUS data base.
 IPP Plan exists in the VisionPLUS data base
 The transaction amount is numeric and is greater than the minimum amount eligible for
IPP conversion.
  The IPP plan is valid.
 The IPP booking is already done for that transaction.
 The CD level of account is less than delinquency roll over defined at plan level.
 If any of the above validation fails, then the response code is not 00.
 Once the validation is successful, the response code is send as zeroes and the cross reference
file is built.
 The cross reference file have card number, reference number, IPP plan and the booking date
and this file is used to avoid duplicate IPP booking. This file also gets logged when the
transaction is converted to IPP through ARTD/ARSD. This ensures that the transactions are not
converted to installments more than one time in a day.
 If IPP booking is again initiated for the same transaction on different day, then the reference
number of installment file is used for identification of duplicate IPP transaction.
 Post successful validation of the incoming request, a credit and debit transaction is created and
the same gets processed in the subsequent EOD batch. For each successful booking of IPP
through API, two transactions, one is credit to the retail plan and a debit to the IPP plan is
posted in the EOD batch which results in creation of IPP plan using online monetary transaction
log file.
 If the transaction which is being booked for IPP has resulted in frequent shopper points, then
these points are not reflected either in credit/debit of the IPP transactions.
 Once the IPP is booked successfully in the system, the record is deleted from the cross reference
file built during the booking of IPP. If the reference number of the cross reference file matches
with the installment file reference number, the same record is deleted from the cross reference
file else the same record is retained in the cross reference file.
 Refer to the 1.2 Reports and extracts for request & response message layout/cross reference
file layout/ online monetary transaction log file layout.

1.1.13.1 General Ledger Requirements for IPP (Installment Payment

Plan)
Transaction
Code Transaction Description
350 INSTALLMENT TRANSFER DEBIT
351 INSTALLMENT TRANSFER CREDIT
361 INSTALLMENT TRANSFER DEBIT
362 INSTALLMENT TRANSFER CREDIT
364 INSTALLMENT ONE TIME FEE

1.1.14 CIF ID Update

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N N N
 AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N N N N N N N N

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

N Y Y Y Y N

 CIF ID can be updated through the API service provided the CIF update service is set as active in
the API parameter screen for the particular product.
 Following validations are performed on the incoming request for updating the CIF.
 Card number should not be spaces/low values
 CIF ID should not be spaces/low values
 Action should be either ‘Y’/’N’
 Card number should be present in NI Card Management System data base
 CIF ID of the card number provided in the incoming request exists in the embosser
logical file for action as ‘Y’.
 CIF ID of the card number provided in the incoming request is zeroes if the action is ‘Y’.
 Explain action field
 Action type can be ‘N’ or ‘Y’
 N – Update CIF ID of provided card number in the incoming message by TIBCO team
 Y – Card number provided in the incoming request is used to read the embosser file and
the CIF ID associated with the card number is considered. All the cards associated with
that CIF ID are updated with the CIF ID provided in the incoming message.
 If any of the above validations fail, then the response code is not zeroes.
 Once the validation is successful, the response code is send as zeroes and the values are
updated in the embosser file along with the non-monetary log update for the generation of the
report in the subsequent EOD batch.
 If the action is provided as ‘N’, then the card number provided in the incoming message only is
updated with the CIF ID provided in the incoming request.
 If the action is ‘Y’, card number provided in the incoming request is used to read the embosser
file and the CIF ID associated with the card number is considered. All the cards associated with
that CIF ID are updated with the CIF ID provided in the incoming message.

Note: Although the setup is done in VisionPLUS, Currently this service is not being used by AUB as
AUB does not have the CIF concept.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.1.15 Rewards Redemption/reversal

AUB KWD AUB GBP AUB SAR UAB NBF BNP
Y Y Y N N N
 AUB AUB AUB UAB NBF BNP BBY DF FGB FGI QIIB
KWD GBP SAR

Y Y Y N N N N N N N Y

ENBD ENBD ENBD ENBD ENBD EIB

(EBI) EURO GBP USD

Y Y Y Y Y Y

1.1.15.1 Rewards Redemption/reversal

 Rewards can be redeemed/ reversed for AUB through API provided the corresponding rewards
service should be set as active for the product in the API parameter screen. This service is
enabled at VisionPLUS, however not activated at TIBCO end.
 Following validations are performed on the incoming request for rewards redemption/reversal.
 Rewards should be set as active at product level.
 Accounts should be activated for rewards
 Account should not be charged off/closed/transferred out/transferred in/purge or to be
purged status.(Refer Account Status and Block Codes document for further details on
account status)
 Block code at account should allow reward redemption.
 Account delinquency level should allow reward redemption.
 Frequent shopper program number should be set up in V+ and should be within the
validation period.
 Sufficient points should be available for rewards redemption.
 Upon successful validation of the incoming request, the corresponding program balance at the
account level is reduced and the CTD DISBURSED is increased for rewards redemption.
 In case of rewards redemption reversal, the CTD earned balance for the respective program is
increased.
 Monetary log is generated and gets processed in the subsequent EOD batch resulting in the
posting of memo transactions.
 A log file is updated to log the rewards redemption/redemption reversal on successful response
and if the incoming message has an indicator to write the log file. This log file is used for
audit/reference purpose.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.1.15.2 Transfer points/ Reverse transfer points

 Rewards can be transferred/ transfer points reversal for AUB through the API service provided
the corresponding rewards service should be set as active in the API parameter screen. This
service is enabled at VisionPLUS, however not activated at TIBCO end.
 Following validations are performed for FROM card (Card from which points are to being
transferred).
  Rewards should be set as active at product level.
 Accounts should be activated for rewards
 Account should not be charged off/closed/transferred out/transferred in/purge or to be
purged status.
 Block code at account should allow reward redemption.
 Account delinquency level should allow reward redemption.
 Frequent shopper program number should be set up in NI Card Management System
and should be within the validation period.
 Sufficient points should be available for rewards redemption.

 Below Validations are performed to validate the TOCARD (Transferred in account/New Card)

 New Card number should be present in embosser database. Hence account transfer
should happen prior to points transfer.
 New account number should be present in base segment database and should be
activated for rewards functionality.
 New Account status should not be charged off/closed/transferred out/transferred
in/purge or to be purged status.
 New account block code/delinquency should allow points adjustment.
 The New Card Product should support the rewards functionality if the new card product
differs from old account Product (product upgrade/downgrade).
 Points transferred should not cause total Year to Date points to exceed the maximum
earned points allowed for the program.

 Upon successful validation of the incoming request, the corresponding program balance of the
FROM card is reduced and for the TO card the corresponding program balance is increased.
 ALL CTD, YTD FS balances are reduced/increased for the FROM/TO card.
 A log file is updated to log the rewards transfer/reverse transfer points on successful response
and if the incoming message has an indicator to write the log file. This log file is used for
audit/reference purpose.
 The data that will be extracted can be seen in the Layout attached in the 1.2 Reports and
extracts

1.2 Reports and Extracts

Payment record layout

AUB

FGB
QIIB

BBY

ENBD (EBI)/ ENBD USD/EBI KSA/EIB/DF

TIBCO request details file layouts

API Layout

IPP cross reference file layout

Online monetary transaction log file layout