0% found this document useful (0 votes)
242 views

Approach Document Power Ecoll

This document outlines Power eColl, a corporate collections solution from Axis Bank that allows corporates to collect payments from partners through NEFT/RTGS transactions with prior validation. Key aspects include: 1) Axis Bank provides a dedicated IFSC and account number for collections. 2) Transactions are validated against the client's partner database via a web service or data hosted with Axis Bank. 3) Once validated and posted, transactions are confirmed to the client in real-time via web service or periodic SFTP files for reconciliation.

Uploaded by

avashborah
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
242 views

Approach Document Power Ecoll

This document outlines Power eColl, a corporate collections solution from Axis Bank that allows corporates to collect payments from partners through NEFT/RTGS transactions with prior validation. Key aspects include: 1) Axis Bank provides a dedicated IFSC and account number for collections. 2) Transactions are validated against the client's partner database via a web service or data hosted with Axis Bank. 3) Once validated and posted, transactions are confirmed to the client in real-time via web service or periodic SFTP files for reconciliation.

Uploaded by

avashborah
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

POWER ECOLL

CLIENT NAME
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 CLIENT ......................................................................... 4
SAMPLE TRANSACTION ...................................................................................................................................... 4
TRANSACTION INITIATED BY AXIS BANK CUSTOMER ........................................................................................ 5
COMMUNICATION FROM CLIENT TO ITS DEALERS ............................................................................................ 5
MIS AND RECONCILIATION ................................................................................................................................ 5
FILE FORMATS / REPORTS / MIS FIELDS............................................................................................................. 6
DO'S AND DON’TS .............................................................................................................................................. 7
SAMPLE WEB SERVICE DETAILS ......................................................................................................................... 8
Validation Service ..................................................................................................................................... 8
Confirmation Service................................................................................................................................. 9

Strictly Confidential. Not for further circulation. Page 1


Since the inception of NEFT and RTGS, there has been an increasing trend amoungst
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 client's systems.

OBJECTIVE

The aim of this document is to describe the approach and process proposed by Axis Bank to
CLIENT 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 CLIENT.
2. Axis Bank has allocated a 4 digit Corporate Code to CLIENT – 1234 (example)
3. Inward NEFT/RTGS received on the specific IFSC shall be validated against the
CLIENT’s partner / dealer database
4. Corporate’s dealer/vendor validation – Online validation data of remitter details
through web service connectivity hosted by CLIENT OR Data Maintained by Axis
Bank
5. Real time MIS (reverse feed) to the corporate, resulting in real time information to
the client over web service connectivity OR near real time feed through SFTP (at
scheduled intervals) OR scheduled MIS through automailers
6. Online platform to view and query transactions, generate reports

Strictly Confidential. Not for further circulation. Page 2


PROCESS OUTLINE

Key steps involved

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

[2] Validation of CLIENT Dealer as per the data maintained in CLIENT 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 CLIENT

[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
CLIENT, real time over web service connectivity OR near real time feed through SFTP (at
scheduled intervals)

[5] CLIENT 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 CLIENT would be required to maintain its data (of its dealers/ remitters/ invoicing
details if applicable) with Axis Bank.

Strictly Confidential. Not for further circulation. Page 3


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 CLIENT

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

1. Transaction validation – Axis Bank to use the method to initiate validation request
by sharing the CLIENT’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, CLIENT 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 client’s end to ensure that multiple
update doesn’t happen in client’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 client’s end

The initial setup shall be tested and UAT shall be done, upon successful confirmation from
CLIENT, 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:

Strictly Confidential. Not for further circulation. Page 4


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>

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 CLIENT TO ITS DEALERS

CLIENT needs to communicate to all the remitters (CLIENT 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

Strictly Confidential. Not for further circulation. Page 5


In case of reconciliation issues ad-hoc MIS can be made available to CLIENT 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)

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)
Virtual unique account number given to pilot
Receiver Account 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 Account Type May be ignored
related ref No May be ignored
Beneficiary May be ignored
Code assigned by the bank to Axis-Tally common
Corporate Code customer
Dealer Code / any other unique code (the
outstanding against a dealer keeps getting knocked
off as and when the inward transactions are
Sub Client Code received)
Sub Client Name May be ignored

Strictly Confidential. Not for further circulation. Page 6


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

DO'S AND DON’TS

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


2. All transactions credited to CLIENT 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 CLIENT Agents be
communicated the details as per the defined process.
4. In case of a connectivity failure at CLIENT, the same should be informed to Axis
Bank.

Points of Caution

1. The transactions on Account number of CLIENT 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 digit which is different from the accepted
code the transaction will be retuned and the amount will not be credited.

Strictly Confidential. Not for further circulation. Page 7


SAMPLE WEB SERVICE DETAILS
Validation Service
Request Parameters for Method1

Field Parameter Parameter M/O Details


name Type
Identifier Appl_User_ID Integer(50) not M Checksum key+ userid Key is given
null below
Request UUID Req_id Char(50) not M Unique id for each request
null
Request Req_dtls char(100) not M Each parameter is separated by “|”
Details null Eg: param1|param2
Request Req_dt_time char(20) not null M YYYY-MM-DD HH24:MI:SS
DateTime
Corporate code Corp_code Char(10) not M Each corporate code will be shared
null 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) not M Hash code/Checksum key+ userid
null Key
Request UUID Req_id Char(50) not M Unique id for each request
null
Request Req_dtls char(100) not M Each parameter is separated by “|”
Details null Eg: param1|param2
Status Flag Stts_flg char(2) not null M Y-Success,F-Failed
Corporate code Corp_code Char(10) not M Each corporate code will be
null shared and same to be populated

Strictly Confidential. Not for further circulation. Page 8


while sending for request.
ErrorCode Err_cd Char(5) O Error Code will be provided in
case any error is occurred
Error Err_desc Char(50) O Error description details
Description

Confirmation Service
Request Parameters for Method 2

Field Parameter Parameter M/O OTC-O Details


name Type NEFT-N
RTGS-R
Identifier Appl_User_ID Integer(50) M Hashcode/Checksum key+
not null userid Key
Request UUID Req_id Char(50) not M Unique id for each request
null
Transaction txn_nmbr char(30) not M
No null
Request Req_dt_time char(20) not M YYYY-MM-DD HH24:MI:SS
DateTime null
Corporate Corp_code Char(10) not M Each corporate code will be
code null shared and same to be
populated while sending for
request.
Transaction Txn_amnt Number(16,4) M Decimal allowed
Amount
PaymentMode pmode Char(1) not M Default “2”
null
Cheque Date Chq_date Char(10) O N/A if Yyyy-MM-dd
Nor R
Cheque Chq_nmbr Char(10) O N/A if Numeric
Number Nor R
Micr Number Micr_nmbr Char(9) O N/A if numeric
Nor R
Payment Flag Stts_flg Char(3) M “000” –success
“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. Page 9


Response Parameters for Method 2

Field Parameter Parameter M/O Details


name Type
Identifier Appl_User_ID Integer(50) not M Checksum key+ userid Key is
null given below
Request UUID Req_id Char(50) not M Unique id for each request
null
Transaction Id txn_id char(30) not null M A unique txn id will be provided
Client Unique Clt_txn_id Char(30) not M Client’s Unique confirmation
ID null number
Corporate code Corp_code Char(10) not M Each corporate code will be
null shared and same to be populated
while sending for request.
Successflag Stts_flg Char(5) M “000”- success
“111”- Failed
ErrorCode Err_cd Char(5) O Error Code will be provided in
case any error is occurred
Error Err_desc Char(50) O Error description details
Description

Strictly Confidential. Not for further circulation. Page 10

You might also like