Bank ODSB system

Abstract

The invention discloses a bank ODSB system. The system comprises five layers of architectures: a data source layer comprising a core business system, a customer relationship management system and the like; the data integration layer performs data cleaning, conversion and loading through an ETL process and comprises an ODSB online data warehouse; the data service layer is used for providing services such as report generation and data analysis in a DataMarts form; the application service layer has the functions of report service, system management and the like, and interacts through a WebServices interface; and the user interaction layer is used for presenting the analysis result in the form of charts and reports. The system adopts a J2EE technical system to construct a front-end framework, and a rear end comprises three stages of ETL processing, data platform management and CIS integration. The physical architecture is configured with a DBSERVER server, an ETLSERVER server, a WEBSERVER server, a CognosSERVER server and the like, and an online storage system and an offline storage system. Unified standardization of branch data models is realized, a whole-bank integrated data service mechanism is established, information islands are broken, repeated construction is reduced, data sharing efficiency is improved, and technical support is provided for digital transformation of banks.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of bank information systems, and in particular to a bank ODSB system. BACKGROUND

[0002] In today's digital era, the banking industry is facing unprecedented challenges and opportunities. With the rapid development of financial technology and the increasing diversification of customer needs, banks need to process massive amounts of transaction data, customer information, and business data to support daily operations, risk management, and decision analysis. In order to more effectively manage these data, provide real-time analysis and insights, and enhance customer service experience, banks are promoting digital transformation and building advanced information system architectures. However, due to historical reasons and business development needs, large banks often adopt branch management mode, and each branch has built its own information management system based on different needs at different times. Although this decentralized system construction mode meets the individual needs of each branch to some extent, it also brings many problems.

[0003] In the prior art, large banks generally have the problem of non-uniform data among branches, and each branch has different information management systems, leading to serious information island phenomenon. Specifically, the data models, data standards, and data formats of each branch are different, making it difficult to realize data interconnection and intercommunication; the information of the same customer in different branches cannot be integrated, affecting the completeness and accuracy of customer profiling; each branch independently processes and analyzes data, resulting in a lot of repeated construction and resource waste; the head office cannot obtain a unified data view of the entire bank, affecting macro decision-making and risk control; business collaboration between branches is difficult, and the advantages of group operation cannot be fully realized. The root cause of these problems lies in the lack of a unified data platform and standardized data management system.

[0004] The above technical problems seriously restrict the business development and management efficiency improvement of banks. Information islands lead to the inability to fully utilize data resources, affecting the response speed of banks to market changes and the quality of customer service; non-uniform data increases the difficulty of regulatory reporting and risk management, which may bring compliance risks; repeated construction results in waste of IT investment and increases system maintenance costs; lack of a unified data view affects the decision-making efficiency and accuracy of management. Therefore, it is urgent to build a unified and standardized data management platform to realize data sharing and business collaboration between the head office and branches, between branches, break down information islands, and establish a unified information service system for customers, accounts, institutions, transactions, channels, and products, etc. to provide solid technical support for the digital transformation and high-quality development of banks. SUMMARY

[0005] The technical problem to be solved by the present application is that large banks have the problem of information islands caused by the fact that the data of each branch is not unified and each branch has a different information management system, which seriously affects the bank's data sharing, business collaboration and decision support capability, and restricts the bank's digital transformation and business development.

[0006] Technical scheme To solve the above technical problems, the present application provides a bank ODSB system, which builds a head office level ODSB, relies on the head office ODSB basic platform, establishes information management platforms of each branch, realizes the index system of information services for each theme of customers, accounts, institutions, transactions, channels and products, and achieves that each branch can share a unified data storage model to provide a unified information view for business personnel at all levels.

[0007] A bank ODSB system, comprising: A data source layer, including internal systems of core business systems and customer relationship management systems, and external data sources of financial market data and third-party service providers; A data integration layer, which collects data from the data source layer through an ETL process and performs cleaning, conversion and loading, and the data integration layer includes an ODSB online data warehouse; A data service layer, which provides data processing services for different business themes in the form of DataMarts, including report generation, data analysis and data mining; An application service layer, which includes report services, system management, metadata management, content management and permission authentication management, and interacts with users and other systems through WebServices interfaces; A user interaction layer, which presents data analysis results to users in the form of charts and reports through theme applications, customer and product management, and business topic management function modules.

[0008] Further, the data architecture of the system comprises: A system data layer, which is the bottom layer and contains the raw data of all business systems of the bank; A basic data layer, which includes ODS, ECIF, ERPF and SMIS, wherein the ODS is responsible for data collection, storage, processing and monitoring, the ECIF is responsible for integrating and managing customer information, the ERPF is responsible for business system integration, and the SMIS is responsible for information system infrastructure support; A common processing layer, which includes data integration, quantitative assessment and report model function modules; An ODM / FDM / MDM layer, wherein ODM is operational data mart, FDM is financial data mart, and MDM is master data management.

[0009] Further, the front-end architecture of the system is built based on the J2EE technology system, which comprises: The client-side information module includes a business topic sub-module, a marketing capability mining sub-module, and a quantitative assessment sub-module. The RIDE+UAAP module includes SUP support tools, COGNOS reporting tools, and RIDE components. The data warehouse module includes program development, management functions, report development, graph development, report display, and data analysis. J2EE technology system module, integrating Servlet, JSP, and EJB components.

[0010] Furthermore, the system's backend architecture includes: During the ETL processing phase, the Control-M scheduling tool is used for data acquisition, the DATASTAGE tool is used for data processing, and the TOAD tool is used to optimize SQL statements. During the data platform management phase, data is managed uniformly through a central control mechanism, using a client / server (C / S) architecture. During the CIS integration phase, Control-M is integrated with the central information system (CIS) to achieve unified management of job scheduling.

[0011] Furthermore, the system's physical architecture includes: Two DBSERVER database servers are set up, one dedicated to the head office ODSB and the other dedicated to the branch ODSB. The DBSERVER servers are connected in a cluster server using a storage sharing method. 1-2 ETLSERVERs are responsible for data extraction, transformation, and loading; One web server front-end server is connected to the database server and eTLServer via the network; One CognosSERVER instance, integrated with CognosBI tools for data analysis and report generation.

[0012] Furthermore, the physical architecture also includes: Storages2, an online storage system, is used to store transaction and business data that can be accessed in real time, and is connected to the DBSERVER and WEBSERVER via the network. The offline storage system Storages1 uses tape libraries and disk array storage devices to store historical and backup data, and is connected to DBSERVER via a network.

[0013] Furthermore, the system's data processing flow includes: The data extraction step involves extracting structured, semi-structured, and unstructured data from the data source. The data transformation step involves cleaning, transforming, and formatting the extracted data; The data loading step involves loading the transformed data into the ODSB; The data analysis and mining steps involve in-depth analysis and data mining using analytical tools in the data service layer. The data service and application process involves presenting the analysis results to the user through the application service layer.

[0014] Furthermore, the various data layers achieve data interconnection and sharing through data interfaces and exchange protocols, and adopt data quality control and verification mechanisms to detect and correct data errors and anomalies through real-time monitoring and regular audits.

[0015] Furthermore, the system has scalability capabilities. Processing capacity can be expanded by increasing the number of DBSERVERs or improving the performance of a single server. The efficiency of corresponding functions can be improved by increasing the number of ETLSERVER, WEBSERVER, and CognosSERVER. Storage capacity can be expanded by adding storage devices or upgrading the performance of the storage system. During the development phase, ETL and WEBSERVER use the same server, but they are deployed separately after the system goes live.

[0016] The technical solution of this invention specifically includes the following five structural parts: First, the overall architecture, as the top-level planning of the system design, defines the overall structure, components, and interaction methods between them. This architecture comprises five layers: the data source layer, the data integration layer, the data service layer, the application service layer, and the user interaction layer. The data source layer includes various internal systems and external data sources; the data integration layer is responsible for data collection, cleaning, transformation, and loading through ETL processes, and includes a high-performance, scalable ODSB online data warehouse; the data service layer provides customized data processing services in the form of DataMarts; the application service layer includes reporting services, system management, metadata management, content management, and access control, interacting through WebServices interfaces; the user interaction layer presents data analysis results through functional modules such as topic applications, customer and product management, and business topic management. The system adopts a closed-loop automated data processing workflow, including five steps: data extraction, data transformation, data loading, data analysis and mining, and data services and applications.

[0017] Second, the data architecture employs a multi-layered design to ensure effective data organization and management. This includes a system data layer, a basic data layer, a common processing layer, and an ODM / FDM / MDM layer. The system data layer contains raw data from all of the bank's business systems; the basic data layer includes key departments such as the ODS, ECIF, ERPF, and SMIS departments, responsible for data management, customer relationship management, system integration, and information system infrastructure support, respectively; the common processing layer includes functional modules such as data integration, quantitative assessment, and reporting models; and the ODM / FDM / MDM layers represent operational data marts, financial data marts, and master data management, respectively. Interconnectivity and data sharing between these layers are achieved through data interfaces and exchange protocols, employing strict data quality control and verification mechanisms.

[0018] Third, the front-end architecture is built on the J2EE technology system and enhanced with the RIDE+UAAP platform to improve the system's scalability and flexibility. It includes a client-side information module, a RIDE+UAAP module, a data warehouse module, and a J2EE technology system module. The client-side information module contains sub-modules for business topics, marketing capability mining, and quantitative assessment; the RIDE+UAAP module includes SUP support tools, COGNOS reporting tools, and RIDE components; the data warehouse module includes program development, management functions, report development, graph development, report display, and data analysis functions; the J2EE technology system module integrates Servlet, JSP, EJB, and other components to achieve modular and component-based development of the front-end application.

[0019] Fourth, the backend architecture is divided into three key stages: ETL processing, data platform management, and CIS integration. The ETL processing stage utilizes the Control-M scheduling tool for data acquisition, processes data using professional ETL tools such as DataStage, and optimizes SQL statements using the TOAD tool. The data platform management stage uses a central control mechanism for unified data management, employing a client / server (C / S) architecture. The CIS integration stage integrates with the central information system through Control-M to achieve unified management and coordinated operation of job scheduling, ensuring all return values ​​meet the head office's task scheduling requirements.

[0020] Fifth, the physical architecture, including server configuration, storage system, data flow path, and expansion strategy. Server configuration includes two DBSERVER database servers (one dedicated to the head office ODSB, and the other to the branch ODSB), 1-2 ETLSERVER servers, one WEBSERVER front-end server, and one CognosSERVER server. The storage system configuration includes both online and offline storage systems. The data flow path includes four stages: data writing, data processing, data reading, and data release. The expansion strategy supports flexible expansion of the DBSERVER, ETLSERVER, WEBSERVER, CognosSERVER, and storage system.

[0021] Through the collaborative efforts of application integration, data services, and data integration, the system achieves full lifecycle management of data. Application integration includes the organic combination of ETL, ODSB, and data warehouse; data services include the collaborative operation of ETL, DataMarts, and DataIntegration; data integration is centered on WebServices, complemented by functional modules such as reporting services, external data management, system management, metadata management, content management, access control and authentication management, third-party plugins, intelligent proxies, frameworks and adapters, service processing, routing, data engine, event handling, object mapping, and knowledge base.

[0022] The beneficial effects of this invention are: First, we standardized the operational data models of branches, integrated existing data, and built a unified branch-level data exchange and processing platform to support the unified deployment of head office data analysis applications in branches, thus completely solving the problems of inconsistent data and standards among branches.

[0023] Second, a bank-wide integrated data service mechanism was established, enabling data sharing and business collaboration between the head office and branches, and between branches, breaking down information silos and improving the bank's overall informatization level.

[0024] Third, by reducing and consolidating data transmission interfaces and processes between headquarters and branches, efficiency is improved and costs are reduced. Through a unified data transmission channel and standardized interface protocols, redundant development and maintenance work between systems is significantly reduced.

[0025] Fourth, we unify the implementation of common data processing activities across branches to reduce redundant investment. By building a common processing layer, we avoid branches from performing the same data processing work repeatedly, thereby improving resource utilization efficiency.

[0026] Fifth, promote the sharing of information system construction experience among various branches. Through a unified platform and standards, the best practices and successful experiences of each branch can be quickly promoted and replicated, thereby improving the overall management level of the bank. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only for this invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a diagram of the overall architecture of the bank ODSB system of the present invention; Figure 2 This is a data architecture diagram of the bank ODSB system of the present invention; Figure 3 This is a diagram of the front-end architecture of the bank ODSB system of the present invention; Figure 4 This is a diagram of the backend architecture of the bank ODSB system of the present invention; Figure 5 This is a physical architecture diagram of the bank ODSB system of the present invention. Detailed Implementation

[0029] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should also be noted that, to make the embodiments more comprehensive, the following embodiments are the best and preferred embodiments, and those skilled in the art can use other alternative methods to implement some well-known technologies; moreover, the accompanying drawings are only for more specific description of the embodiments and are not intended to specifically limit the present invention.

[0030] It should be noted that the use of terms such as "an embodiment," "an embodiment," "an exemplary embodiment," and "some embodiments" in the specification indicates that the described embodiment may include a specific feature, structure, or characteristic, but not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, when a specific feature, structure, or characteristic is described in connection with an embodiment, implementing such a feature, structure, or characteristic in conjunction with other embodiments (whether explicitly described or not) should be within the knowledge of those skilled in the art.

[0031] Generally, terms can be understood at least partly from their use in context. For example, depending at least partly on the context, the term "one or more" as used herein can be used to describe any feature, structure, or characteristic in a singular sense, or a combination of features, structures, or characteristics in a plural sense. Additionally, the term "based on" can be understood not necessarily to convey an exclusive set of factors, but rather, alternatively, depending at least partly on the context, to allow for the presence of other factors that are not necessarily explicitly described.

[0032] See Figures 1 to 5 As shown Example 1: Overall Implementation of a Bank's ODSB System This embodiment provides a bank ODSB (Operational Data Store Banking) system. This system establishes a head office-level ODSB basic platform and builds information management platforms for each branch. It realizes an indicator system for information services on various themes such as customers, accounts, institutions, transactions, channels, and products, and solves problems such as inconsistent data and information silos among branches of large banks.

[0033] The overall implementation of the system involves the collaborative construction of five major architectural components. The first step is to implement the overall architecture, which serves as the top-level plan for the system design, defining the overall structure, components, and interaction methods between them. The overall architecture consists of five layers: the data source layer serves as the data input for the entire system, including various internal systems such as core business systems and customer relationship management systems, as well as external data sources such as financial market data and third-party service providers; the data integration layer, through the ETL (Extract, Transform, Load) process, is responsible for collecting data from the data source layer, cleaning, transforming, and loading it into the ODSB. This layer contains the ODSB itself, a high-performance, scalable online data warehouse that supports rapid querying and analysis of massive amounts of data; the data service layer exists in the form of DataMarts, providing customized data processing services for different business themes, including report generation, data analysis, and data mining; the application service layer contains a series of applications and services, such as reporting services, system management, metadata management, content management, and permission / authentication management, which interact with users and other systems through WebServices interfaces; and the user interaction layer, as the final output of the system, presents complex data analysis results to users in the form of charts, reports, etc., through functional modules such as theme applications, customer and product management, and business topic management.

[0034] The data processing workflow employs a closed-loop automated process: extracting necessary data from various data sources, including structured, semi-structured, and unstructured data; cleaning, transforming, and formatting the extracted data to ensure accuracy and consistency; loading the transformed data into the ODSB for subsequent data analysis and services; utilizing the data in the ODSB, conducting in-depth analysis and data mining through various analytical tools and techniques provided by the data service layer to discover underlying patterns and trends; and presenting the analysis results to users in an intuitive manner through the application service layer, supporting the bank's decision-making, risk management, and customer service. Key components include the ODSB as the core component of the system, responsible for storing and managing the bank's massive amounts of data, featuring high availability, scalability, and high performance; ETL tools that automate the data extraction, transformation, and loading processes; DataMarts providing customized data processing services for different business themes; WebServices interfaces providing a standard, cross-platform interface specification; and security and access control mechanisms ensuring that only authorized users can access and use the data and services in the system.

[0035] Example 2: Specific Implementation of Data Architecture In this embodiment, the data architecture adopts a multi-level design. The system data layer, as the bottom layer of the data architecture, contains the raw data from all the bank's business systems. This data comes from different business lines such as deposits, loans, payments, and investments. The system data layer is responsible for data collection, storage, and preliminary processing. In the basic data layer (level 3), the data is further integrated and standardized. This layer includes key departments such as the ODS department, ECIF department, ERPF department, and SMIS department. The ODS department is responsible for data collection, storage, processing, and monitoring, ensuring data quality and security through the establishment of comprehensive data management processes and standards. The ECIF department, as the customer relationship management department, is responsible for integrating and managing customer information, including basic customer information, transaction records, risk preferences, etc., providing the bank with accurate customer profiles and personalized service solutions through in-depth analysis of customer information. The ERPF department and SMIS department are respectively responsible for the integration of business systems and information system infrastructure support. The ERPF department achieves data sharing and process collaboration between different business systems by building a unified business platform, while the SMIS department is responsible for the construction and maintenance of the information system.

[0036] In the implementation of the common processing layer (level 4), data is further processed and refined. This layer includes multiple functional modules such as data integration, quantitative assessment, and report models. Through in-depth analysis and mining of basic data, various business indicators, reports, and models are generated. In the implementation of the ODM / FDM / MDM layers, ODM (Operational Data Mart) focuses on the analysis and application of operational data, FDM (Financial Data Mart) focuses on the integration and analysis of financial data, and MDM (Master Data Management) is responsible for the unified management and maintenance of master data. These layers together constitute the data warehouse system of the bank's ODSB system. During the implementation of data flow and integration, data starts from the system data layer, undergoes integration and processing in the basic data layer, and then enters the common processing layer for in-depth analysis and mining. Various functional modules achieve data interconnection and sharing through data interfaces and exchange protocols. At the same time, a strict data quality control and verification mechanism is adopted. Through real-time monitoring and regular auditing of data, data errors and anomalies are promptly detected and corrected.

[0037] Example 3: Specific Implementation of Front-End Architecture The front-end architecture is implemented based on the J2EE technology framework. J2EE, as a mature enterprise-level application development framework, provides rich components and services such as Servlet, JSP, and EJB. Combined with the RIDE+UAAP platform, it enhances the system's scalability and flexibility. The client-side information module implementation includes three main parts: a business topic module responsible for displaying various topical data closely related to banking business, such as deposit and loan analysis and risk management, intuitively showing business operation status through charts and reports; a marketing capability mining module utilizing data mining and machine learning techniques to analyze customer behavior and transaction data, discovering potential marketing opportunities and customer needs; and a quantitative assessment module based on preset KPIs (Key Performance Indicators) to quantitatively assess banking business and evaluate the work performance of employees and departments.

[0038] In the implementation of the RIDE+UAAP module, SUP provides basic support services for the front end, such as user authentication and permission management; COGNOS reporting integrates COGNOS reporting tools to design and generate complex reports; RIDE components, as one of the core components of the RIDE+UAAP platform, provide rich data visualization functions and interactive interface design tools. The data warehouse module implementation includes program development, responsible for data interaction and business logic processing between the front end application and the data warehouse, implementing operations such as querying and updating the data warehouse through Java and other backend programs; management functions provide system-level management functions such as data management, user management, and log auditing; report development, graph development, and report display combine COGNOS reporting and RIDE components to develop various forms of reports and graphs, which are displayed to users through a web interface, while providing flexible report customization and export functions; data analysis utilizes data in the data warehouse for in-depth analysis and mining. The J2EE technology system module, as the underlying support of the entire front end architecture, provides a stable and efficient development and runtime environment for front end applications, realizing modular and component-based development of front end applications by integrating various J2EE components and services.

[0039] Example 4: Specific Implementation of Backend Architecture The implementation of the backend architecture is divided into three key phases. In the ETL processing phase, data acquisition utilizes the Control-M scheduling tool issued by the head office. As a powerful enterprise-level job scheduling system, Control-M can efficiently manage and coordinate the execution of a large number of jobs, ensuring the accuracy and timeliness of data acquisition. Data processing is performed using ETL task development tools, prioritizing professional ETL tools such as DATASTAGE, as they offer rich data processing capabilities and optimized performance. At the same time, reliance on stored procedures is minimized to reduce system complexity and maintenance costs. For scenarios where stored procedures must be used, SQL statements must be optimized using tools such as TOAD. TOAD can analyze the performance bottlenecks of SQL statements and provide optimization suggestions, significantly improving data processing efficiency.

[0040] During the data platform management phase, the data platform uses a central control mechanism to manage data uniformly, ensuring data consistency and integrity. This mechanism includes data quality checks, data access control, and data backup and recovery. The system adopts a client / server (C / S) architecture, dividing the system into client and server components. The client handles user interaction and data processing requests, while the server handles data storage and business logic processing. This architecture offers advantages such as good scalability and low maintenance costs, meeting the bank's ODSB system's requirements for high concurrency and large data volume processing. During the CIS integration phase, the bank's ODSB system integrates with CIS (Central Information System) through Control-M to achieve unified management and coordinated operation of job scheduling. Control-M, as the core tool for job scheduling, ensures efficient collaboration between the ODSB system and CIS in data flow and job execution. During data processing and integration, all return values ​​must meet the head office's task scheduling requirements, and the processing results at each stage undergo rigorous verification and confirmation to ensure data accuracy and integrity.

[0041] Example 5: Specific Implementation of Physical Architecture The physical architecture server configuration includes: Two DBSERVER servers are configured as database servers, one dedicated to the head office ODSB and the other to the branch ODSB. This configuration ensures data independence while facilitating horizontal scaling. DBSERVER servers share storage, and a cluster of servers is established to improve system reliability and performance. One to two ETLSERVER servers are configured to handle data extraction, transformation, and loading. The specific number is adjusted based on the processing capacity of the branch database servers and business needs. ETLSERVER servers extract data from the source system, clean and transform it, and then load it into the DBSERVER servers. One WEBSERVER server is configured as the front-end server, responsible for handling user access requests and providing a graphical interface for user interaction. It connects to the DBSERVER and ETLSERVER servers via the network to enable real-time data querying and display. One CognosSERVER server is configured for data analysis and report generation, integrating the CognosBI (Business Intelligence) tool to support complex data analysis and report design.

[0042] There are two types of storage system configurations: Online storage (Storages2) is used to store data that is accessed in real time, including transaction data and business data. It provides high-speed data read and write capabilities to ensure that the system can respond quickly to user query requests. The online storage system is connected to the DBSERVER and WEBSERVER through the network to realize real-time data transmission and sharing. Offline storage (Storages1) is used to store historical data, backup data, and other data that is not frequently accessed. It uses large-capacity, low-cost storage devices such as tape libraries and disk arrays. The offline storage system is connected to the DBSERVER through the network and performs data backup and migration regularly. The implementation of the data flow path includes: In the data writing phase, the data source system writes transaction data to the online storage system, while ETLSERVER periodically extracts data from the data source system, cleans and transforms it, and then loads it into DBSERVER; In the data processing phase, DBSERVER further processes and stores the loaded data, including index creation, data compression, and data encryption; CognosSERVER reads data from DBSERVER for analysis and report generation based on business needs; In the data reading phase, users access the ODSB system through WEBSERVER, and WEBSERVER reads data from DBSERVER based on user query requests and displays it to the user through a graphical interface; In the data release phase, for data that is no longer needed, the system migrates it from the online storage system to the offline storage system for long-term storage or deletes it.

[0043] The expansion strategy includes: DBSERVER expansion by increasing the number of DBSERVERs or improving the performance of individual servers to extend the system's processing capacity, while establishing a server cluster to improve system reliability and performance; ETL, WEB, and CognosSERVER expansion based on business needs, increasing the number of ETLSERVERs to improve the efficiency of data extraction and transformation, increasing the number of WEBSERVERs to improve the concurrent access capabilities of the front-end interface, and increasing the number of CognosSERVERs to improve the speed and accuracy of data analysis; storage system expansion by adding storage devices or upgrading the performance of the storage system to extend the system's storage capacity, while optimizing the layout and configuration of the storage system to improve data read / write speed and security; during the development phase, ETL and WEBSERVER can use the same server to save resources, but after the system goes live, it is recommended to deploy them separately to improve system stability and security.

[0044] Through the above implementation methods, the bank ODSB system of the present invention can achieve a unified and standardized branch operational data model, integrate existing data, build a unified branch-level data exchange and processing platform, support the unified deployment of head office data analysis applications in branches, establish a bank-wide integrated data service mechanism, reduce and consolidate data transmission interfaces and links between head office and branches, improve efficiency, and reduce costs; uniformly implement common data processing activities of branches, reducing redundant investment; and promote the sharing of information system construction experience among various branches, thereby effectively solving problems such as inconsistent data and information silos among branches of large banks, and providing strong technical support for the bank's digital transformation and business development.

[0045] This invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of this invention. To provide the public with a thorough understanding of this invention, specific details are described in detail in the following preferred embodiments; however, those skilled in the art will fully understand the invention even without these details. Furthermore, to avoid unnecessary misunderstanding of the essence of this invention, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0046] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A bank ODSB system, characterized in that, include: The data source layer includes internal systems such as core business systems and customer relationship management systems, as well as external data sources such as financial market data and third-party service providers; The data integration layer collects, cleans, transforms, and loads data from the data source layer through an ETL process. The data integration layer includes the ODSB online data warehouse. The data service layer, in the form of DataMarts, provides data processing services for different business themes, including report generation, data analysis, and data mining. The application service layer includes reporting services, system management, metadata management, content management, and access control management. It interacts with users and other systems through WebServices interfaces. The user interaction layer presents data analysis results to users in the form of charts and reports through thematic applications, customer and product management, and business topic management modules.

2. The bank ODSB system according to claim 1, characterized in that, The system's data architecture includes: The system data layer, as the lowest layer, contains the raw data of all the bank's business systems; The basic data layer includes the ODS department, ECIF department, ERPF department, and SMIS department. The ODS department is responsible for data collection, storage, processing, and monitoring; the ECIF department is responsible for integrating and managing customer information; the ERPF department is responsible for business system integration; and the SMIS department is responsible for information system infrastructure support. The common processing layer includes functional modules for data integration, quantitative assessment, and report modeling. The ODM / FDM / MDM layer consists of an operational data mart, a financial data mart, and a master data management layer.

3. The bank ODSB system according to claim 1, characterized in that, The system's front-end architecture is built on the J2EE technology framework, including: The client-side information module includes a business topic sub-module, a marketing capability mining sub-module, and a quantitative assessment sub-module. The RIDE+UAAP module includes SUP support tools, COGNOS reporting tools, and RIDE components. The data warehouse module includes program development, management functions, report development, graph development, report display, and data analysis. J2EE technology system module, integrating Servlet, JSP, and EJB components.

4. The bank ODSB system according to claim 1, characterized in that, The backend architecture of the system includes: During the ETL processing phase, the Control-M scheduling tool is used for data acquisition, the DATASTAGE tool is used for data processing, and the TOAD tool is used to optimize SQL statements. During the data platform management phase, data is managed uniformly through a central control mechanism, using a client / server (C / S) architecture. During the CIS integration phase, Control-M is integrated with the central information system (CIS) to achieve unified management of job scheduling.

5. The bank ODSB system according to claim 1, characterized in that, The physical architecture of the system includes: Two DBSERVER database servers are set up, one dedicated to the head office ODSB and the other dedicated to the branch ODSB. The DBSERVER servers are connected in a cluster server using a storage sharing method. 1-2 ETLSERVERs are responsible for data extraction, transformation, and loading; One web server front-end server is connected to the database server and eTLServer via the network; One CognosSERVER instance, integrated with CognosBI tools for data analysis and report generation.

6. The bank ODSB system according to claim 5, characterized in that, The physical architecture also includes: Storages2, an online storage system, is used to store transaction and business data that can be accessed in real time, and is connected to the DBSERVER and WEBSERVER via the network. The offline storage system Storages1 uses tape libraries and disk array storage devices to store historical and backup data, and is connected to DBSERVER via a network.

7. The bank ODSB system according to claim 1, characterized in that, The data processing flow of the system includes: The data extraction step involves extracting structured, semi-structured, and unstructured data from the data source. The data transformation step involves cleaning, transforming, and formatting the extracted data; The data loading step involves loading the transformed data into the ODSB; The data analysis and mining steps involve in-depth analysis and data mining using analytical tools in the data service layer. The data service and application process involves presenting the analysis results to the user through the application service layer.

8. The bank ODSB system according to claim 2, characterized in that, Data layers are interconnected and shared through data interfaces and exchange protocols. Data quality control and verification mechanisms are adopted to detect and correct data errors and anomalies through real-time monitoring and regular audits.

9. The bank ODSB system according to claim 5, characterized in that, The system has scalability, which can be expanded by increasing the number of DBSERVERs or improving the performance of a single server, improve the efficiency of corresponding functions by increasing the number of ETLSERVER, WEBSERVER, and CognosSERVER, and expand storage capacity by adding storage devices or upgrading the performance of the storage system. During the development phase, ETL and WEBSERVER use the same server, but are deployed separately after the system goes live.

Images