Power eColl

Integrated Receivables Solution

 Contents
INTRODUCTION 2
OBJECTIVE 2
PROCESS FLOW: CORPORATE COLLECTIONS - INWARD NEFT/RTGS 2
PROCESS OUTLINE 3
VALIDATION MECHANISM – DATA HOSTED BY AXIS BANK 3
VALIDATION MECHANISM – WEBSERVICE HOSTED BY CORPORATE 3
SAMPLE TRANSACTION 4
TRANSACTION INITIATED BY AXIS BANK CUSTOMER 4
Communication from Corporate to Dealers/Vendors 5
MIS AND RECONCILIATION 5
FILE FORMATS / REPORTS / MIS FIELDS 5
DO'S AND DON’TS 7
Sample Web Service 7
Validation Service 7
Confirmation Service 9

Strictly Confidential, not for further circulation

 INTRODUCTION

Since the inception of NEFT and RTGS, there has been an increasing trend amongst
Corporates to move from paper based transactions to electronic transaction
mode. NEFT and RTGS transactions are credited directly to the customer accounts;
many customers find it difficult to reconcile the transactions based on the credit
transaction information alone. Power eColl solution from Axis Bank provides a fully
integrated solution for enabling e-collections for the corporate customers with
capabilities like online validation over web service connectivity and real time
transaction update directly to the CORPORATE's systems.

OBJECTIVE

The aim of this document is to describe the approach and process proposed by
Axis Bank to CORPORATE for providing Power eColl solution and Host to Host
integration. The solution enables a corporate to collect from its partners / dealers/
agents with prior validation of the transaction and capability to update its ERP or
Accounting Software.

PROCESS FLOW: CORPORATE COLLECTIONS - INWARD NEFT/RTGS

KEY HIGHLIGHTS

1. Axis Bank to provide specific IFSC for enabling corporate collections –

UTIB0CCH274. This IFSC is different from the IFSC of the account of CORPORATE.

2. Axis Bank has allocated a 4 digit Corporate Code to CORPORATE – 1234

(example)

3. Inward NEFT/RTGS received on the specific IFSC shall be validated against the
CORPORATE’s partner / dealer database

4. Corporate’s dealer/vendor validation – Online validation data of remitter details

through web service connectivity hosted by CORPORATE OR Data Maintained by
Axis Bank

5. Real time MIS (reverse feed) to the corporate, resulting in real time information
to the CORPORATE over web service connectivity OR near real time feed through
SFTP (at scheduled intervals) OR scheduled MIS through auto mailers

6. Online platform to view and query transactions, generate reports

Strictly Confidential, not for further circulation

 PROCESS OUTLINE

Key steps involved

[1] Remitter (CORPORATE Dealer) initiates NEFT / RTGS to IFSC – UTIB0CCH274 A/C
No. 1234ABCD1234

[2] Validation of CORPORATE Dealer as per the data maintained in CORPORATE

system, over web service connectivity OR Data Maintained by Axis Bank

[3] If validation is successful, Axis Bank to process the transaction. The credit of the
transaction would be done in the current account of CORPORATE

[4] Once the transaction is successfully posted in the current account and related
accounting entries completed at Axis Bank’s end, transaction processing update is
sent to CORPORATE, real time over web service connectivity OR near real time
feed through SFTP (at scheduled intervals)

[5] CORPORATE to provide transaction confirmation to Axis Bank for the step [4] OR
provide for duplicate (in case of a reattempt in posting the transaction
confirmation) – applicable only in case of web service update

VALIDATION MECHANISM – DATA HOSTED BY AXIS BANK

The CORPORATE would be required to maintain its data (of its dealers/ remitters/
invoicing details if applicable) with Axis Bank.

1. Incremental addition / deletion / modification of data to be shared to Axis Bank

at regular intervals.
2. Data sharing to be done through registered email IDs of the corporate with a
centralized Axis Bank back office team.

VALIDATION MECHANISM – WEBSERVICE HOSTED BY CORPORATE

CORPORATE to host the web services and provide access credentials to Axis Bank
with methods for:

Strictly Confidential, not for further circulation

 1. Transaction validation – Axis Bank to use the method to initiate validation request
by sharing the CORPORATE’s dealer code (invoice number or any other unique
identifier) for validation. There can be multiple parameters in the validation request
also. Amount validation can also be done in case required.

2. Confirmation (reverse feed post transaction being accounted for in Axis Bank) –
Axis to confirm the transaction posting by sharing the transaction details over web
service.

3. At the time of confirmation, CORPORATE server to send an acknowledgement

(of receiving transaction update). Acknowledgement can be a response code
which shall be configured. Dedupe to be built-in at CORPORATE’s end to ensure
that multiple update doesn’t happen in CORPORATE’s end.

a. Axis to reattempt transaction posting till it receives and acknowledgement

response code OR a duplicate.
b. This is to ensure that transaction is definitely updated and logs maintained at
both Axis Bank and CORPORATE’s end

The initial setup shall be tested and UAT shall be done, upon successful confirmation
from CORPORATE, the setup shall be moved in to live environment,

Axis Bank IPs to be whitelisted – List of IPs to be provided by Axis Bank, in case of
any changes necessary update shall be communicated.

SAMPLE TRANSACTION

A remitter would initiate an NEFT / RTGS from any bank to a specific IFSC of Axis
Bank. The transaction can be initiated by a remitter from any channel offered by
the remitter’s bank, for instance internet banking, mobile banking or from the
branch. The following details would be required by the remitter to initiate the
transaction:

Beneficiary Account Number: 1234<Followed by dealer code / agent code in

continuation without space, in CAPS>

For example: 1234ABCD1234

Beneficiary IFSC: UTIB0CCH274

Please note that beneficiary account number is case sensitive.

TRANSACTION INITIATED BY AXIS BANK CUSTOMER

If a remitter is an Axis Bank customer, still an NEFT is required to be initiated. The

remitter can initiate the NEFT through Internet Banking or from an Axis Bank branch
by providing the following details:

Beneficiary Account Number: 1234<Followed by dealer / agent code in

continuation without space, in CAPS>

Strictly Confidential, not for further circulation

 For example: 1234ABCD1234

Beneficiary IFSC: UTIB0CCH274

Axis Bank customers can also add the virtual account 1234ABCD1234 as a beneficiary in
Mobile Banking and make payments 24x7x365 days.

Communication from Corporate to Dealers/Vendors

Corporate needs to communicate to all the remitters (Dealers/Agents) to transact

using NEFT irrespective of any banking relationship (i.e. Axis Bank or other banks).

The beneficiary details as under:

Beneficiary Account Number: 1234<Followed by agent id in continuation without

space, in CAPS>

Beneficiary IFSC: UTIB0CCH274

MIS AND RECONCILIATION

1. Hourly and EoD MIS can be setup to authorised email recipients

2. Power eColl WebCMS (online portal) for download or MIS

In case of reconciliation issues ad-hoc MIS can be made available to Corporate for
the collections processed by Axis Bank. The concerned Relationship Manager
should be contacted for the same.

FILE FORMATS / REPORTS / MIS FIELDS

Mode of MIS delivery

 SFTP
 Automailers
 Web-service based reverse feed

Frequency – SFTP based MIS delivery can be scheduled at an agreed frequency

(upwards of every 15 minutes)

Strictly Confidential, not for further circulation

 Report Fields

MIS Fields Description

TRAN ID Transaction ID
Sender IFSC IFSC code of remitter
Account type A/C type of remitter
Sender Account A/C no of the remitter
Sender Name Name of the remitter
Sender Address Address of remitter – if captured
Receiver IFSC UTIB0CCH274 (fixed input)
Receiver Account Virtual unique account number given to pilot remitter
Receiver Name Name of beneficiary as captured by initiating bank
REMARKS May be ignored
Tran amount Amount of the txn
Tran Date Date of Txn
Tran Type NEFT / RTGS / WithinBank
Beneficiary
May be ignored
Account Type
related ref No May be ignored
Beneficiary May be ignored
Corporate Code Code assigned by the bank to Axis-Tally common customer
Dealer Code / any other unique code (the outstanding against a dealer
Sub Corporate
keeps getting knocked off as and when the inward transactions are
Code
received)
Sub Corporate
May be ignored
Name

Please note: Sequencing and selection of relevant of the report fields can be done
as per the requirement.

File Name: Name can be customized with the following options:

 Field1: Unique Starting String (can be account number of the Axis-Tally

customer)
 Field2: Any other identifier
 Field3: Transaction Type (optional)
 Field4: Sequence Number
 Field5: Suffix (optional, but for EoD consolidated MIS would be EOD)

File Types

1. TXT – Pipe separated text file with or without header

2. CSV
3. XLS

Strictly Confidential, not for further circulation

 DO'S AND DON’TS

1. All transactions initiated from CORPORATE Agents to be only on UTIB0CCH274

IFSC
2. All transactions credited to YTS account shall be reflected in the Current
Account statement once the validation of the transaction is successful and
executed
3. Test transactions should be done once the system is live and the YTS Agents be
communicated the details as per the defined process.
4. In case of a connectivity failure at CORPORATES, the same should be informed
to Axis Bank.

Points of Caution

1. The transactions on Account number of CORPORATES and IFSC of the branch in

which the account is maintained shall not be subject to the validation rules as
agreed and tested.
2. MIS / Reverse feed shall be only for the transactions posted on IFSC UTIB0CCH274
3. The account statement shall have all the transactions received inclusive of the
transactions received on the actual account number and IFSC. The count and
total of such transaction should be excluded at the time when recon is being
done.
4. In case Axis Bank Receives an incorrect IFSC code the transaction will be
retuned and the amount will not be credited.
5. In case the Bank receives the first four digits which is different from the accepted
code the transaction will be retuned and the amount will not be credited.

Sample Web Service

Validation Service
Request Parameters for Method1

Field Parameter Parameter M/O Details

name Type
Identifier Appl_User_ID Integer(50) M Checksum key+
not null userid Key is given
below
Request Req_id Char(50) not M Unique id for each
UUID null request
Request Req_dtls char(100) M Each parameter is
Details not null separated by “|”
Eg:
param1|param2
Request Req_dt_time char(20) not M YYYY-MM-DD
DateTime null HH24:MI:SS

Strictly Confidential, not for further circulation

 Corporate Corp_code Char(10) not M Each corporate
code null code will be shared
and same to be
populated while
sending for request.

[M = Mandatory, O = Optional]

1. Req_ID - Request ID parameter value will be populated by Axis Bank which is

unique
2. Appl_User_ID - Application user id parameter value will be generated with
combination of validation no. & key shared in the document.
3. Req_dtls - Request Details parameter value will be populated in the form of string
which is pipe separated (|).
a. Param1 will be always the validation unique no in the request /UTR
b. Param2 will be populated subsequently as per the corporate request. Currently it
will be blank
4. Corp_code - Corporate Code is a value which will be shared during any the
onboarding.

Response parameters for Method1

Field Parameter Parameter M/O Details

name Type
Identifier Appl_User_ID Integer(50) M Hash
not null code/Checksum
key+ userid Key

Request Req_id Char(50) M Unique id for each

UUID not null request
Request Req_dtls char(100) M Each parameter is
Details not null separated by “|”
Eg:
param1|param2

Status Flag Stts_flg char(2) not M Y-Success,F-Failed

null
Corporate Corp_code Char(10) M Each corporate
code not null code will be
shared and same
to be populated
while sending for
request.

ErrorCode Err_cd Char(5) O Error Code will be

provided in case
any error is
occurred

Strictly Confidential, not for further circulation

 Error Err_desc Char(50) O Error description
Description details

Confirmation Service

Request Parameters for Method 2

OTC-O
Parameter Parameter
Field M/O NEFT-N Details
name Type
RTGS-R

Integer(50) Hashcode/Checksum
Identifier Appl_User_ID M
not null key+ userid Key
Char(50) not Unique id for each
Request UUID Req_id M
null request
char(30) not
Transaction No txn_nmbr M
null
Request char(20) not YYYY-MM-DD
Req_dt_time M
DateTime null HH24:MI:SS

Each corporate code

Corporate Char(10) not will be shared and same
Corp_code M
code null to be populated while
sending for request.

Transaction
Txn_amnt Number(16,4) M Decimal allowed
Amount
Char(1) not
PaymentMode pmode M Default “2”
null

Transaction N/A if
Chq_date Char(10) O Yyyy-MM-dd
Date Nor R

N/A if
UTR Number Chq_nmbr Char(10) O Numeric
Nor R

“000” –success
Payment Flag Stts_flg Char(3) M
“111”- failed

OTC = Over the counter collections (i.e. Axis Bank Branch collections. In case only branch
collections are being done, NEFT / RTGS would become not applicable)

Strictly Confidential, not for further circulation

 Response Parameters for Method 2

Parameter Parameter
Field M/O Details
name Type

Integer(50) Checksum key+ userid Key is given

Identifier Appl_User_ID M
not null below

Char(50) not
Request UUID Req_id M Unique id for each request
null

char(30) not
Transaction Id txn_id M A unique txn id will be provided
null

Char(30) not
YTS Unique ID Clt_txn_id M YTS’s Unique confirmation number
null

Each corporate code will be shared

Corporate Char(10) not
Corp_code M and same to be populated while
code null
sending for request.

“000”- success
Successflag Stts_flg Char(5) M
“111”- Failed

Error Code will be provided in case

ErrorCode Err_cd Char(5) O
any error is occurred

Error
Err_desc Char(50) O Error description details
Description

Strictly Confidential, not for further circulation

 Version Control

Ver. No. Author Description Date

1.0 Hariharan R Initial Draft

1.1 Dhiraj Dhakite Updated Version

Strictly Confidential, not for further circulation