At present, in the field of Internet finance, each company has different process modes for post-loan system. If we use the post-loan system currently sold in the market, the cost of customization will be too high and there will be a risk of leakage of important data. Therefore, completely relying on service providers cannot well adapt to our development mode and ever-changing needs. Under this environment, the automobile post-loan management system platform is born.
It is particularly important to establish a post-loan management system that covers all credit products, runs through the whole business process and monitors the macro and micro aspects. Standardizing post-loan business management process can improve the quality of post-loan management, reduce bad loans, stabilize the quality of assets, effectively manage resources, and finally achieve the goal of comprehensively improving the quality of loans.
The system is divided into four modules according to its functions, namely: repayment module, asset preservation module, automobile service module and message centre module. The repayment module mainly provides the follow-up and review functions of various repayment orders and contracts and carries out compulsory or self-operated repurchase according to the overdue situation of borrowers. This module includes four sub-modules: repayment management, repurchase review, contract management and financial statements.
The asset preservation module mainly introduces record of demanding payment and task distribution. It also carries out demanding payment internally and outsourcing management based on the difficulty of cases, and carries out online reduction and updates repayment schedule for overdue problems not caused by the customers themselves.
Through delimiting the scope of electronic fence and the data reported by wired GPS and wireless GPS, the automobile service module makes it easy for service personnel to view the automobile tracks and carry out risk warning and quasi real-time control on automobiles after loan. This module includes five sub-modules, such as automobile monitoring alarm, return visit work order, GPS work order, electronic fence and traffic violation management.
Message centre module mainly serves the whole system, which is convenient for system users to call and send short messages with one key. It includes message template preset, routing rules setting, send out message, call out and record query.
This chapter mainly describes the overall technical framework, and then divides and introduces the functional structure of each module in detail.
1.1 System Structure
The system adopts B/S structure and the whole system is developed by the separation of front end and back end. The back-end uses Spring, Spring MVC, My Batis (SSM) structure and Java language for development. The front-end interface is mainly developed with java script language and vue framework. The front and back ends are deployed independently and communicate by ajax. The whole system structure is divided into four layers. From top to bottom, there are display layer, service layer, component layer and data layer. This structure design can ensure the loose coupling of the system. Meanwhile, the design can satisfy the expansibility of the upper layer of the system. Figure 1-1 shows the structure of the automobile post-loan management system.
Figure 1-1 Frame diagram for development
Cluster, as well as the use and packaging of es-sql. It provides a simple and easy-to-use interface for the upper layer, shielding the difficult technical barriers of the upper layer, and also provides a standardized interface for the service layer to access these common components.
The fourth layer is the data layer: this layer mainly provides direct data access for the system, such as the access to MySQL, the processing of sub database and sub table, and the processing of writing the data of elasticsearch sub index. The existence of this layer shields the complex operation of the interaction between the bottom layer and db.
1.2 System Functional Structure
Adhering to the principle of “high cohesion, low coupling”, this section divides the functional modules of the whole system in combination with the functional and non-functional requirements of the system. The whole system is divided into four major modules, and all functions of the system are realized by these four modules and their sub-modules. The functional module division of the system is shown in Figure 1-2.
Automobile Post Loan System
Figure 1-2 System structure diagram
1.2.1 Design of Repayment Module
The repayment module, as the repayment entrance of the system, not only guarantees the normal repayment process, but also bears the responsibility of communicating with the financial system and the capital.
In the design of the module, the interaction with the financial system and the capital is carried out through Dubbo RPC. At the same time, the capital’s system will push a batch of data to this module every half an hour. In consideration of interface flow control and message consistency, we use the Rabbit MQ message queue of ACK mechanism for processing. The functional structure of the repayment module is shown in Figure 1-3.
Design & Repayment Module
Figure 1-3 Structure diagram of repayment module
The repayment module is mainly used to manage the process of different repayment types and the repurchase process for overdue risk automobiles. Enum is used to enumerate different operations of contract processing and different types of repayment and repurchase. In the process of executing repayment, the contract ID is used to query the repayment type and its order status in the repayment information table. In the process of repayment audit, the risk status of the order will be obtained through Dubbo service to judge whether the financial review process can be carried out. After the review is passed, this module continues interacting with the financial system through Dubbo RPC to deal with the repayment. If the contract is classified as a risk contract in the asset preservation module, and the capital requires to settle the payment in advance, then a repurchase process will be carried out. The settlement request of the capital and the repayment module of the system also communicate through dubbo service. In the process of two dubbo services, the contract ID is defined as the unique key for connection with the financial system, and the unique order ID is defined separately for interaction with the capital. Since the data interaction mechanism with the capital is to push a batch of loan order related information to the interface of repayment module every half an hour, we use Rabbit Mq message queue with ACK mechanism for flow control to prevent the interface from collapsing due to too much pressure.
1.2.2 Design of Asset Preservation Module
The asset preservation module is responsible for the import and distribution of overdue data as well as the application and audit of penalty and interest reduction in the system. The distribution process of overdue data is completed at the time of data import. Data can be imported by timing task or triggered manually. For the consideration of current data level and interface flow control, Kafka message queue is selected for data import and multiple partitions are used for concurrent processing to improve the speed of data writing and consumption. Overdue data distribution rules and penalty interest reduction rules are dynamic and pluggable design, which can be added or deleted at will to flexibly respond to business changes. At the same time, the process of demanding payment internally and outsourcing management after case classification depends on the calling and sending short messages function of the message centre module. The functional structure of the asset preservation module is shown in Figure 1-4:
Asset Preservation Model
Figure 1-4 Structure diagram of asset preservation module
In the asset preservation module, data is the basis of all business functions. The data used for the follow-up of collectors in asset preservation exists in the external data source pool, which can be triggered in two ways: timing script and manual trigger. The timing script runs at 8 o’clock every day to import the overdue data of the deadline program. Manual mode can be triggered at any time, mainly as a supplement to timing mode. Imported data cannot be used directly. Data cleansing and distribution rules need to be configured. The module also provides the function of sending short message and calling out. Both the two services connect with their respective service providers through their respective channel proxy. Due to the large number of messages, the actual logic of message sending is to write a message sending request to the Kafka message queue, and to limit the flow of message sending by asynchronously consuming the topic of Kafka, so as to prevent the message sending interface from collapsing.
1.2.3 Design of Automobile Service Module
The automobile service module provides the system with various work order management, automobile monitoring and alarm functions. The automobile monitoring alarm is mainly realized through electronic fence. The creation and query of electronic fences are realized through Baidu Map and Elasticsearch, and the automobile monitoring and alarm are realized through esri-geometry-api, Kafka and Prometheus. This module also provides the function of calling out and sending short messages, which are realized through the api provided by the message centre module. The functional structure of this module is shown in Figure 1-5:
Automobile Service Module
Figure 1-5 Structure diagram of automobile service module
This section mainly introduces the logic design and implementation of the whole process of automobile monitoring and warning function. There are three main types of monitoring alarm, namely real-time manufacturer alarm, real-time operation alarm and asynchronous operation alarm. The three are described as follows:
- Real-time manufacturer alarm: alarm data will be generated directly by the manufacturer and processed directly by the system, such as photosensitive, flipping, etc.
- Real-time operation alarm: it is triggered by wireless GPS signal or position information, and the alarm is calculated from travel data, GPS terminal data and existing alarm data and inserted into the database, such as device separation alarm, fence alarm, etc.
- Asynchronous operation alarm: batch calculation by time, calculating results according to the travel data, GPS terminal data and existing alarm data, such as wired and offline alarm, wireless and offline alarm, etc.
1.2.4 Design of Message Centre Module
The message centre module provides a unified entrance for the system to dial telephone and send messages. The module connects with telephone service providers and message service providers, and realizes the routing and forwarding of telephone and message requests through its own rules, so as to provide unified telephone dialing and message sending functions for other modules. The implementation of this module relies on Redis to control the interval of requests. Message sending function also needs message template configuration. Message without preset template will not be sent. At the same time, the module also provides a short message record query and call record query function. The functional structure of the message centre is shown in Figure 1-6:
Message Centre Module
Figure 1-6 Structure diagram of message centre module
In the design of sending short message function, the main body processes the call request asynchronously through Kafka message queue. The main purpose is to increase the interface throughput and reduce the peak in rush hours. Secondly, part of the alarm data is shared by different business logic and stored in the message queue, which is convenient for other users to subscribe directly. The background of the program will open multiple consumers (multiple group IDs), monitor the same topic in real time, and process the subsequent logic concurrently. First, each call-out will record a message in Redis, and each request will be cached to determine if the same phone number has been called within 60 seconds. If the cache validation passes, a request is first logged and stored in the database.
The design idea of message sending function is similar to that of telephone calling function. Both of them are to achieve interacting with service providers and shield the details of invocation by setting proxy class, so as to expose the unified access format to the outside. This proxy class is actually our own protocol.
This paper aims to build a set of automobile post-loan management system which is in line with the company’s business process and adapts to the company’s rapid development mode. With the increasingly fierce competition in the Internet finance industry, post-loan management becomes more and more important in the loan process. Therefore, it is necessary to establish a perfect post-loan system in order to control loan risks and the occurrence of non-performing loans. We need to unify and standardize business, reduce the company’s investment in maintenance costs and improve the work efficiency of business personnel through technical means. In order to achieve this goal, we provide borrowers with a variety of repayment modes. For overdue contracts, we automatically distribute cases according to certain rules, so as to facilitate the collection personnel to follow up. Meanwhile, we also carry out real-time monitoring and risk early warning for automobiles to facilitate automobile service personnel to timely control risks and provide corresponding risk plans for existing problems, and finally to guarantee the safety of enterprise assets and reduce the investment in maintenance costs of the company to a certain extent.
Mr Chen (2nd from left) attended the Auto finance industry in 2019. As a representative of Da Souche he was there to release the industries Auto Finance Early Warning Risk Platform.