Approach Document Power Ecoll
Approach Document 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
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.
KEY HIGHLIGHTS
[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
The CLIENT would be required to maintain its data (of its dealers/ remitters/ invoicing
details if applicable) with Axis Bank.
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:
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:
Axis Bank customers can also add the virtual account 1234ABCD1234 as a beneficiary in Mobile
Banking and make payments 24x7x365 days.
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).
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
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
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.
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.
Confirmation Service
Request Parameters for Method 2