Sales Draft Automation

 

A sales draft is a record indicating that a cardholder has completed a purchase. A sales draft is provided at the end of a transaction made by a payment card, such as a credit card, confirming that the transaction was processed. It is a legally binding agreement between the cardholder and the organization that provided the good or service that the cardholder purchased.

• A sales draft is a record of a purchase of goods or services, made by a cardholder, and handed out at the end of a transaction.
• Typically, a credit card is swiped, the financial institution that holds the account is contacted, the cardholder's ability to cover the purchase is verified, and the transaction is processed.

After the completion of this process, which usually happens instantaneously, a physical or digital sales draft is provided and the cardholder must sign, verifying that they will pay.

 

How a Sales Draft Works

 

·       When a payment card is used in the purchase of a good or service, the swipe of that card into a terminal sets off a series of digital processes designed to determine whether the cardholder has the funds available to make the purchase. A card acqirer encrypts the cardholder’s information and sends it to the card processor, which decrypts this information, verifies that the cardholder has sufficient funds, and then sends a confirmation to the card terminal indicating that the transaction is valid. This entire process is typically instantaneous.

·       Once the card processor has approved a transaction the cardholder indicates that the sale is final by signing a receipt. The receipt is traditionally printed, but for some transactions, the receipt may be provided electronically. The cardholder signs the physical receipt or electronic receipt acknowledging that a good or service has been purchased and that they promise to pay the amount indicated on the receipt. The receipt then serves as a record of the transaction.

Challenges

• Want to Automate the whole process as the current system is legacy and does not support SD receival.
• Get Original Receipt from merchant for Customer to keep for Personal records or future dispute.
• Integrate the solution with Visa and Mastercard association which have build the new system for Sales draft documents.
• Do not have any Ability to attach the letter on existing case as the system are old.
• Require system from where Agent can Accept/Reject the letter.
• Auto Order Sales Draft for Fraud and Non-Fraud Dispute.
• Attach the Sales draft to existing Dispute case which will help closing the dispute and chargeback process.

Architecture Solution

 

·       As-Is Architecture

 

As is architecture does not have any automation in place and most of the process is manual where Agent need to login into MC and VISA on regular basis and download the SD once its available . They have to download locally and then attached the same on the cases.

·       To-Be Architecture

New Design will complete the required automation which is key business Objective of the automation.

Also this solution support multiple channel without much development.

·       Request will be submitted from any channel (desktop/WEB/Mobile/BPM/etc..)

·       Channel will mark the case in Pending state as well.

·       Update the corresponding records in Database

·       Respective Channel will call the API (Microservice API build on Spring boot) for the backend system to take care of retrieval and processing of the documents.

·       API will initiate a call to get the Claim/Case Id from the Association (Visa/MC).

·       Above data will be stored in the Mongo Database.

·       Batch (Spring Batch) will pick up all the active records from Mongo (not older than 30 days) and start polling the VISA/MC queue.

·       Batch will also upload the document into CMOD which is Document Management solution.

·       Once the document received Batch will update the channel with CMOD Ref id and update Mongo DB.

·       Channel will retrieve the document from CMOD and update the Case status.

·      

 

 

Platform Architecture: OpenShift Enterprise has a microservices-based architecture of smaller, decoupled units that work together. It can run on top of (or alongside) a Kubernetes cluster, with data about the objects stored in etcd, a reliable clustered key-value store. Those services are broken down by function:

·       REST APIs, which expose each of the core objects.

·       Controllers, which read those APIs, apply changes to other objects, and report status or write back to the object.

 

Business Objective and Benefits

 

·       The bank has seen a host of business benefits from its initial implementation. Chief among these is a 30% acceleration of Sales Draft Processing which directly impacts the quality of the customer experience.  No Manual Intervention to retrieve/upload/download documents.  Solution delivered this by eliminating multiple days of work and duplication in the process, automatically enforcing the movement of work to its next step. Other received benefits include full process visibility, increased data quality, less re-work, and decreased training times. The improved SD processing systems helps the bank achieve its mission critical business objectives by integrating disparate legacy systems, overlaying them with a more flexible, natively mobile architecture and social interfaced Provide improved workflow system gives them the tools needed to increase efficiency, while collaborating with customers through a simple, user friendly interface. Processing time of the Sales Draft reduced from 30 Days to 5 days.       Number of FTE required to process the sales draft request is cut down by 30%. Documents Available for Dispute and Chargeback processing allowed back office customer to process the Dispute in less time. Reduce the processing time of such claims where SD is required by 50%.