Routing Number Validation

Request/Response & Json Schema

Overview

The interface is used to validate routing number with ALIP system. The third party applications like portal or eApp captures bank account details for customers in the application for setting up premium or disburse claim amount to the customers. The bank routing number can be validated against those available in the ALIP system to check if it is already present. The interface also provided bank details for the routing number when it is listed in the ALIP system.

The request is in form of 230/23002 ACORD format. The client applications can send ACORD request over SOAP/REST/JMS. The interface can validate one routing number at a time using this interface. The interface checks if routing number is present in the ALIP system. The response contains details like it is a valid routing number if present in the ALIP system. It also contains bank name and from which date onwards the routing number is active.

Technical Requirements

TR ID# Technical Requirements
TR1 ACORDv2.36 shall be used to communicate.
TR2 Routing Number Request “integrationPoint=ROUTING_VALIDATION” should be used for executing interface
TR3 Interface must always return an error code and desc in the event of a transaction processing failure in addition to HTTP response code.
TR4 For a successful transaction execution (when transaction is able to check routing number in the ALIP system) HTTP return code of 200 is returned.
TR5 For a failed transaction execution or XSD check failure, HTTP return code of 400 is returned

Business Requirements

BR ID# Business Requirements
BR1 The input request will be validated against the routing number present within the ALIP database
BR2 In case of an routing number is present in the ALIP system, a success message will be returned by the interface. Successful response message will also include bank name and date from which routing number is valid
BR3 In case of an routing number is not present in the ALIP system, a success with info message will be returned by the interface. The response message will be “Invalid Routing Number”.
BR4 In case of when request is invalid format or request has duplicate TranRefGUID, an error message with suitable description and code will be returned by the interface.

Process Flow Diagram

Process Flow Description

ALIP will receive a new request for validating routing number, on the ALIP Request Queue.

The ALIP process server will pick up the message. It will first validate request for correct input using. If there is any issue in request input, an integration failure would be created and stored in ALIP and error response is returned.

ALIP will transform the ACORD message to ALIP format, and invoke the necessary APIs to get bank details from the ALIP system. If routing number is present in the ALIP system, it will also get bank details from the ALIP database

The retrieved information which contains bank details for routing number present in the ALIP or no bank details for routing number not listed in the ALIP. The information would be transformed back to ACORD format and sent back to the calling system with suitable return code and message.

Impact on ALIP system

N/A

Assumptions

Routing number stored in the ALIP system are all valid routing number with correct bank details provided.

Dependencies

N/A

Request Data Elements

Response Data Elements

Success/Error Handling

Success Success Scenario Description Message Code Message Description Message Type Additional Comments
#1 The routing number validation interface call was successfully able to fetch bank details 1 Success Informational TXLife/TXLifeResponse/TransResult/ResultCode/@tc =1
#2 The routing number interface call was not able to get bank details as routing number not present the ALIP system 2 Invalid Routing Number Informational TXLife/TXLifeResponse/TransResult/ResultCode/@tc =2
#3 The routing number validation interface call failed with XSD/Duplicate TransRefGUID/System error. 5 General Error Informational TXLife/TXLifeResponse/TransResult/ResultCode/@tc =5