CN115880047A - 一种配置化的银行交易额度管控系统 - Google Patents
一种配置化的银行交易额度管控系统 Download PDFInfo
- Publication number
- CN115880047A CN115880047A CN202211695748.9A CN202211695748A CN115880047A CN 115880047 A CN115880047 A CN 115880047A CN 202211695748 A CN202211695748 A CN 202211695748A CN 115880047 A CN115880047 A CN 115880047A
- Authority
- CN
- China
- Prior art keywords
- transaction
- limit
- quota
- data
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本发明涉及银行交易管控技术领域,公开了一种配置化的银行交易额度管控系统,其技术方案要点是包括交易额度系统和额度服务平台;所述交易额度系统用于在支付过程中进行额度检查,根据检查结果反馈支付系统;所述交易额度系统包括额度参数配置子系统、额度查询服务子系统以及额度计算子系统,所述额度参数配置子系统用于额度指标、标准数据源、指标限额的配置;所述额度查询服务子系统,用于对外提供数据接入和内部数据输出服务;所述额度计算子系统,用于事中额度累计和限额控制,以及事后额度提交或还原,持久化源数据和指标;所述额度服务平台,用于对接所述交易额度系统,为用户提供额度服务。
Description
技术领域
本发明涉及银行交易管控技术领域,更具体地说,它涉及一种配置化的银行交易额度管控系统。
背景技术
近年来,随着电信诈骗愈演愈烈,各银行为保障资金安全,降低风险,对各场景资金交易做了不同额度限制。2016年,中国人民银行便发布了《关于加强支付结算管理防范电信网络新型违法犯罪有关事项的通知》,对I类户做出明确限制,保护资金安全。随着银行业务发展,业务种类的不断开展,同一客户涉及的交易种类越来越多,大多数银行出于资金安全需要,会对客户进行分渠道限额和限制次数,如高风险客户单笔不超1万元,单日不超5万元,单日不超过2次;ATM取款、线上转账或POS交易都设置了不同的额度限制。
大多数银行额度管控的策略采用“谁需要,谁管理”的原则,额度管控分散于各个业务产品线,管理起来较为混乱,功能重复建设,浪费人力成本;新业务场景额度接入需投入成本和时间开发上线,不能快速满足业务需求;部分场景甚至存在交叉管理,严重影响用户体验。银行中各系统分散管理限额,具有重复建设,数据不统一等痛点。
发明内容
本发明的目的是提供一种配置化的银行交易额度管控系统,通过分散的系统架构,能够适用于不同的数据库,可采用分布式多环境部署装,外部系统可通过接入银行交易额度管控系统实现统一的额度累计和限额管控,交易额度系统能够提供多指标额度查询服务,满足业务额度查看需要。
本发明的上述技术目的是通过以下技术方案得以实现的:一种配置化的银行交易额度管控系统,包括交易额度系统和额度服务平台;
所述交易额度系统用于在支付过程中进行额度检查,根据检查结果反馈支付系统;所述交易额度系统包括额度参数配置子系统、额度查询服务子系统以及额度计算子系统,所述额度参数配置子系统用于额度指标、标准数据源、指标限额的配置;所述额度查询服务子系统,用于对外提供数据接入和内部数据输出服务;所述额度计算子系统,用于事中额度累计和限额控制,以及事后额度提交或还原,持久化源数据和指标;
所述额度服务平台,用于对接所述交易额度系统,为用户提供额度服务。
作为本发明的一种优选技术方案,在支付过程中进行额度检查时,如检查通过,则支付系统的交易继续进行,并将交易结果告知交易额度系统;如检查不通过,则支付系统的交易终止。
作为本发明的一种优选技术方案,额度服务中心包括:
对外接入模块,用于为外部系统接入交易额度系统提供标准接口,用于同步用户设置的交易额度数据至交易额度系统,用于为交易额度系统提供对外查询服务,用于在用户交易时对接交易额度系统对当前交易进行限额控制;
数据源管理模块,用于统一接入的外部数据属性;
核心计算模块,用于对接交易额度系统提供限额管理和额度累计服务;
数据持久模块,用于缓存所有交易数据。
作为本发明的一种优选技术方案,所述额度计算子系统中设置有配置化的额度累计和额度管控模型,所述额度累计和额度管控模型在交易事中时,将交易数据转换为标准数据进行校验,若校验通过则进行指标的匹配,得到对应的指标集合,再利用lua脚本进行额度累计并判断与配置限额的大小;
所述额度累计和额度管控模型在交易事后时,将交易数据和交易结果数据转换为标准数据,判断该交易是否进行了事中交易,若存在,则进行指标的匹配获得指标集合,若交易结果为成功,则进行额度提交;若交易结果为失败,则进行额度释放。
作为本发明的一种优选技术方案,对外接入模块包括额度累计模块、限额同步模块、额度查询模块和限额控制模块;
额度累计模块是用于外部系统接入交易额度服务而提供的标准接入接口,定义了用于额度累计所需的业务属性;
限额同步模块是用于将用户设置的交易额度数据同步到交易额度系统,并在交易额度系统保存用户设置的额度,当用户交易时,会根据交易场景判断是否满足额度限制;
额度查询模块用于对外提供额度查询服务;
限额控制模块用于在用户交易时,将本次交易金额和场景信息传入交易额度系统,通过交易额度系统判定是否满足交易限额条件。
作为本发明的一种优选技术方案,数据源管理模块包含数据源定义模块和数据源转换模块;
数据源定义模块用于规范数据接入形式;
数据转换模块用于定义标准数据属性,将所有外部数据统一转为标准数据属性。
作为本发明的一种优选技术方案,核心计算模块包括限额管理模块和额度累计模块,
限额管理模块用于进行限额配置、限额计算和限额控制,限额配置为针对各不通交易场景设置一定的交易限额;限额计算为依赖于额度累计模块,判断额度累计后数值是否大于限额配置金额;限额控制是根据限额计算结果,采用lua脚本,判断额度是否超限;
额度累计模块用于进行指标维度建立、累计条件过滤、额度锁定、额度释放和指标累计。
作为本发明的一种优选技术方案,数据持久化模块包含源数据持久化模块和指标持久化模块;
源数据持久化模块用于将每笔交易数据持久化保存到HIVE数据库,用于在异常场景下,数据追偿;
指标持久化模块用于将缓存数据库中累计的指标额度保存到数据库。
综上所述,本发明具有以下有益效果:本发明的银行交易额度管控系统,通过分散的系统架构,能够适用于不同的数据库,可采用分布式多环境部署装,外部系统可通过接入银行交易额度管控系统实现统一的额度累计和限额管控,交易额度系统能够提供多指标额度查询服务,满足业务额度查看需要。
并且本发明的额度参数配置子系统能够支持新业务指标和限额的配置化接入,指标维度和额度类型支持动态调整,无需系统发布,实时配置,实时生效,便于实际银行对于额度的灵活使用和配置;同时本发明的额度计算子系统能够支持高并发事中额度累计和限额控制,从而可以保证交易准确性;还能够通过交易额度系统实现全行统一的额度管理视图,便于实际银行业务管理。
附图说明
图1是本发明的额度服务中心示意图;
图2是本发明的事中额度累计和额度管控模型示意图;
图3是本发明的时候额度累计和额度管控模型示意图;
图4是本发明的交易额度系统数据结构图;
图5是本发明的支付交易生命周期示意图;
图6是本发明的事中额度累计示意图;
图7是本发明的事中额度控制示意图;
图8是本发明的事后额度提交示意图。
具体实施方式
以下结合附图对本发明作进一步详细说明。
本发明提供一种配置化的银行交易额度管控系统,包括交易额度系统和额度服务平台;
交易额度系统用于在支付过程中进行额度检查,如检查通过,则支付系统的交易继续进行,并将交易结果告知交易额度系统;如检查不通过,则支付系统的交易终止;接口调用遇到超时,根据不同业务场景采取不同的处理策略。
交易额度系统包括额度参数配置子系统、额度查询服务子系统以及额度计算子系统。
额度参数配置子系统用于额度指标、标准数据源、指标限额的配置,额度计算和控制过程中会取配置数据参与计算和控制;
额度查询服务子系统,用于对外提供数据接入和内部数据输出服务;
额度计算子系统,用于事中额度累计和限额控制,以及事后额度提交或还原,持久化源数据和指标是交易额度系统数据计算中枢。
交易额度系统的数据结构如图4所示,其中:
数据源:数据源即接入其它系统已有的交易数据,接入形式分为两种,事中同步RSF(一种RPC)接口调用和事后KAFKA抛送。事中RSF调用配置RSF接口要素信息,系统启动时会加载该服务,注册到服务中心,供其它系统调用;事后通过KAFKA形式将交易交过抛送到交易额度系统,数据源需配置KAFKA信息,包括主题(topic)、组(groupId)、服务集群(bootstrapServers)、版本(clusterVersion)和注册中心(zk),系统启动时,会加载KAFKA配置信息,监听topic消息;
数据源属性:接口调用时传送的字段信息,如账户、金额、流水号、日期等信息;
标准数据属性:额度累计计算过程中使用的字段信息,由于系统兼容多数据源数据,每个数据源对同一含义定义的字段值不一致,如A系统定义金额字段为amt,B系统定义金额字段为amount,为后续方便额度计算,通过转换算法,将各数据源字段统一转为标准字段;
数据集:数据源的集合,归集多个数据源,当某一指标用到多个数据源数据才能完成计算时,需将多个数据源归集到一个数据集下;
指标:额度计算核心模型,配置化生成额度累计指标,包括额度累计类型:单日限额、单月限额、年度限额、单日次数、单月次数、年度次数;累计字段(通常为交易金额字段,次数默认每笔交易加1次);依赖的数据集;累计维度(卡号维度、手机号维度或身份证维度,支持多字段组合维度配置,如账号+卡类型);
限额:基于指标配置业务限额,限额类型同步指标类型加单笔限额共7种;
名单:限额名单,支持单维度和组合维度名单定义。
额度计算子系统中设置有配置化的额度累计和额度管控模型,如图2和3所示,额度累计和额度管控模型在交易事中时,将交易数据转换为标准数据进行校验,若校验通过则进行指标的匹配,得到对应的指标集合,再利用lua脚本进行额度累计并判断与配置限额的大小;额度累计和额度管控模型在交易事后时,将交易数据和交易结果数据转换为标准数据,判断该交易是否进行了事中交易,若存在,则进行指标的匹配获得指标集合,若交易结果为成功,则进行额度提交;若交易结果为失败,则进行额度释放。
具体的,如图5所示,交易额度系统将一笔交易分为事中事后两个阶段,事中指用户发起支付,支付系统调用通达资金转出前这一阶段;事后指支付通道返回支付结果,支付结果又分为支付成功和支付失败两种情况;
事中额度累计:如图6所示,交易额度系统接收到数据源发送的数据,根据数据源标识,通过数据集,加载出所属的所有指标,同时根据数据源属性将所有字段映射为标准数据属性。循环遍历所有指标,过滤掉不满足指标自身设置的条件的指标,满足条件的指标会根据其配置的额度累计类型和累计维度分类计算;
事中额度控制:如图7所示,事中限额建立在额度指标基础上,根据指标维度设置限额指标。限额指标分为两类,一是业务限额,没有指定具体限额名单,针对涉及到的指标生效;二是名单限额,限额关联客户名单(身份证或卡号),每个名单用户单独设置限额类型,名单限额类型继承系统限额类型,名单限额值不大于系统限额,如限额值为空,则认为不限制。为支持分布式并发场景下限额管控,额度累计和限额控制均采用Redis Lua脚本原子化执行,保证额度累计和限额管控的正确性。
事后额度提交(回滚):如图8所示,支付结果通过kafka形式将结果抛送指交易额度系统,交易额度系统根据支付结果进行对应处理:支付成功,额度提交;支付失败,额度回滚。
额度服务平台,用于对接交易额度系统,为用户提供额度服务,上述的所有交易额度服务在执行时,均通过额度服务平台来实现。
如图1所示,额度服务中心包括:
对外接入模块,用于为外部系统接入交易额度系统提供标准接口,用于同步用户设置的交易额度数据至交易额度系统,用于为交易额度系统提供对外查询服务,用于在用户交易时对接交易额度系统对当前交易进行限额控制;
数据源管理模块,用于统一接入的外部数据属性;
核心计算模块,用于对接交易额度系统提供限额管理和额度累计服务;
数据持久模块,用于缓存所有交易数据。
具体的,对外接入模块包括额度累计模块、限额同步模块、额度查询模块和限额控制模块;
额度累计模块的作用是在外部系统接入交易额度系统时而提供标准接入接口,该接口定义了用于额度累计所需的业务属性,包括交易金额、交易账户、交易流水、交易时间、接入渠道等信息,外部系统将自身交易信息通过该接口传入,该接口接收到数据后,通过数据源管理模块对数据清洗转换,再通过核心计算模块将本次交易数据累计到各个指标上;
限额同步模块的作用是:将用户通过渠道app设置的交易额度数据同步到交易额度系统,包括线上转账的单笔、单日限额,POS消费的单笔、单日限额及单日交易笔数交易,交易额度系统保存用户设置的额度,当用户交易时,会根据交易场景判断是否满足额度限制。
额度查询模块用于为交易额度系统对外提供额度查询服务,如购买理财或转账到他行卡时,各银行卡支持的单笔、单日限额信息和剩余可用额度信息。
限额控制模块的作用是:用户交易时,将本次交易金额和场景等信息传入交易额度系统,交易额度系统根据场景、金额等信息判定是否满足交易限额条件,如不满足,则本次交易失败,如反洗钱名单用户,单笔交易限额1万元、单日限额5万元,如单笔超过1万或单日超5万则交易失败。
数据源管理模块包含数据源定义模块和数据源转换模块;
数据源定义模块用于规范数据接入形式,包括http形式、RSF形式和kafka形式等,外部系统通过以上3种形式的任意一种或者其他形式接入即可;
数据转换模块用于定义标准数据属性,交易额度系统对外接入多种多样数据源,为便于数据计算,将所有外部数据统一转为标准数据属性,如A系统金额字段定义为money,B系统金额字段定义为amt,标准数据属性定义为amount,最后A\B系统金额统一转为amount进行计算。
核心计算模块包括限额管理模块和额度累计模块;
限额管理模块包括限额配置、限额计算和限额控制3方面,限额配置是针对各不通交易场景设置一定的交易限额,如转账,单笔不超过50万,单日不超过100万;限额计算依赖于额度累计模块,判断额度累计后数值是否大于限额配置金额;限额控制是根据限额计算结果,如超过配置限额,则返回上游额度超限,不允许交易。限额计算采用lua脚本,将当前配置限额、当前已用金额和当前交易金额输入lua脚本,得到额度是否超限的结果。
额度累计模块用于进行指标维度建立、累计条件过滤、额度锁定、额度释放和指标累计,指标维度建立是指各场景都建立独立的额度累计指标,指标包含本场景要累计的维度信息,如反洗钱指标,根据客户号累计单日额度;累计条件过滤是判断交易数据是否满足某个指标的条件,满足条件的指标才会进行额度累计;额度锁定指事中交易,额度会进行提前累计,防止并发场景下额度超限,无法控制;额度释放是根据最终交易结果判断额度是否还原:交易成功--额度提交,交易失败--额度释放;指标累计是指满足累计条件的数据,将交易金额和次数累计到对应的指标上,如存在多个指标都满足,则每个指标都累计。
数据持久化模块包含源数据持久化模块和指标持久化模块。
源数据持久化模块用于将每笔交易数据持久化保存到HIVE数据库,可用于在系统异常场景下,数据追偿。
指标持久化模块用于将缓存数据库中累计的指标额度保存到数据库,防止缓存数据库宕机数据丢失。
本发明的优势在于:本发明的银行交易额度管控系统,通过分散的系统架构,能够适用于不同的数据库,可采用分布式多环境部署装,外部系统可通过接入银行交易额度管控系统实现统一的额度累计和限额管控,交易额度系统能够提供多指标额度查询服务,满足业务额度查看需要。
并且本发明的额度参数配置子系统能够支持新业务指标和限额的配置化接入,指标维度和额度类型支持动态调整,无需系统发布,实时配置,实时生效,便于实际银行对于额度的灵活使用和配置;同时本发明的额度计算子系统能够支持高并发事中额度累计和限额控制,从而可以保证交易准确性;还能够通过交易额度系统实现全行统一的额度管理视图,便于实际银行业务管理。
以上所述仅是本发明的优选实施方式,本发明的保护范围并不仅局限于上述实施例,凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理前提下的若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (8)
1.一种配置化的银行交易额度管控系统,其特征是:包括交易额度系统和额度服务平台;
所述交易额度系统用于在支付过程中进行额度检查,根据检查结果反馈支付系统;所述交易额度系统包括额度参数配置子系统、额度查询服务子系统以及额度计算子系统,所述额度参数配置子系统用于额度指标、标准数据源、指标限额的配置;所述额度查询服务子系统,用于对外提供数据接入和内部数据输出服务;所述额度计算子系统,用于事中额度累计和限额控制,以及事后额度提交或还原,持久化源数据和指标;
所述额度服务平台,用于对接所述交易额度系统,为用户提供额度服务。
2.根据权利要求1所述的一种配置化的银行交易额度管控系统,其特征是:在支付过程中进行额度检查时,如检查通过,则支付系统的交易继续进行,并将交易结果告知交易额度系统;如检查不通过,则支付系统的交易终止。
3.根据权利要求2所述的一种配置化的银行交易额度管控系统,其特征是:额度服务中心包括:
对外接入模块,用于为外部系统接入交易额度系统提供标准接口,用于同步用户设置的交易额度数据至交易额度系统,用于为交易额度系统提供对外查询服务,用于在用户交易时对接交易额度系统对当前交易进行限额控制;
数据源管理模块,用于统一接入的外部数据属性;
核心计算模块,用于对接交易额度系统提供限额管理和额度累计服务;
数据持久模块,用于缓存所有交易数据。
4.根据权利要求3所述的一种配置化的银行交易额度管控系统,其特征是:所述额度计算子系统中设置有配置化的额度累计和额度管控模型,所述额度累计和额度管控模型在交易事中时,将交易数据转换为标准数据进行校验,若校验通过则进行指标的匹配,得到对应的指标集合,再利用lua脚本进行额度累计并判断与配置限额的大小;
所述额度累计和额度管控模型在交易事后时,将交易数据和交易结果数据转换为标准数据,判断该交易是否进行了事中交易,若存在,则进行指标的匹配获得指标集合,若交易结果为成功,则进行额度提交;若交易结果为失败,则进行额度释放。
5.根据权利要求4所述的一种配置化的银行交易额度管控系统,其特征是:对外接入模块包括额度累计模块、限额同步模块、额度查询模块和限额控制模块;
额度累计模块是用于外部系统接入交易额度服务而提供的标准接入接口,定义了用于额度累计所需的业务属性;
限额同步模块是用于将用户设置的交易额度数据同步到交易额度系统,并在交易额度系统保存用户设置的额度,当用户交易时,会根据交易场景判断是否满足额度限制;
额度查询模块用于对外提供额度查询服务;
限额控制模块用于在用户交易时,将本次交易金额和场景信息传入交易额度系统,通过交易额度系统判定是否满足交易限额条件。
6.根据权利要求5所述的一种配置化的银行交易额度管控系统,其特征是:数据源管理模块包含数据源定义模块和数据源转换模块;
数据源定义模块用于规范数据接入形式;
数据转换模块用于定义标准数据属性,将所有外部数据统一转为标准数据属性。
7.根据权利要求6所述的一种配置化的银行交易额度管控系统,其特征是:核心计算模块包括限额管理模块和额度累计模块,
限额管理模块用于进行限额配置、限额计算和限额控制,限额配置为针对各不通交易场景设置一定的交易限额;限额计算为依赖于额度累计模块,判断额度累计后数值是否大于限额配置金额;限额控制是根据限额计算结果,采用lua脚本,判断额度是否超限;
额度累计模块用于进行指标维度建立、累计条件过滤、额度锁定、额度释放和指标累计。
8.根据权利要求7所述的一种配置化的银行交易额度管控系统,其特征是:数据持久化模块包含源数据持久化模块和指标持久化模块;
源数据持久化模块用于将每笔交易数据持久化保存到HIVE数据库,用于在异常场景下,数据追偿;
指标持久化模块用于将缓存数据库中累计的指标额度保存到数据库。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211695748.9A CN115880047A (zh) | 2022-12-28 | 2022-12-28 | 一种配置化的银行交易额度管控系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211695748.9A CN115880047A (zh) | 2022-12-28 | 2022-12-28 | 一种配置化的银行交易额度管控系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115880047A true CN115880047A (zh) | 2023-03-31 |
Family
ID=85754868
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211695748.9A Pending CN115880047A (zh) | 2022-12-28 | 2022-12-28 | 一种配置化的银行交易额度管控系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115880047A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112396426A (zh) * | 2020-11-20 | 2021-02-23 | 交通银行股份有限公司 | 一种跨行支付额度监测方法、系统及计算机存储介质 |
-
2022
- 2022-12-28 CN CN202211695748.9A patent/CN115880047A/zh active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112396426A (zh) * | 2020-11-20 | 2021-02-23 | 交通银行股份有限公司 | 一种跨行支付额度监测方法、系统及计算机存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101791849B1 (ko) | 현금 자동 입출금기 거래 차단 | |
CN109087431B (zh) | 银行网点的业务调度处理方法、设备和存储介质 | |
CN109325734A (zh) | 一种财务机器人系统 | |
CN108734457B (zh) | 一种统一收银系统下的退款方法 | |
CN107833124A (zh) | 基于财务总账数据的财务分析系统及实现方法 | |
KR101364763B1 (ko) | 금융거래패턴분석을 이용한 금융사기 경보 시스템 및 방법 | |
CN110084048B (zh) | 一种银行统一用户管理的实现方法 | |
CN1914895A (zh) | 利用电话进行安全金钱支付带锁银行电脑帐务系统和方法 | |
CN108830697A (zh) | 一种业财一体化系统和方法 | |
CN111382150A (zh) | 一种基于Flink的实时计算方法及系统 | |
US20170270496A1 (en) | Instant funds availablity risk assessment and real-time fraud alert system and method | |
CN108009818A (zh) | 一种基于分布式网络的线上支付方法及系统 | |
CN107194810A (zh) | 资产配置系统和方法 | |
CN115880047A (zh) | 一种配置化的银行交易额度管控系统 | |
US20220292470A1 (en) | Systems and methods for domestic and/or cross border blockchain transaction solutions involving central bank digital currency | |
CN108711045A (zh) | 一种收银系统和收银方法 | |
CN112991046A (zh) | 电子资源的额度控制方法、装置、设备及存储介质 | |
CN108762727B (zh) | 一种事件驱动的财务信息处理方法和系统 | |
CN108009916A (zh) | 一种基于事务动态调整的通用支付记账的方法以及系统 | |
CN108985701A (zh) | 一种一号通系统及其数据管理方法 | |
CN101276501A (zh) | 可全面取代硬币的零钱找续的系统和相应方法 | |
CN108765107A (zh) | 一种业财一体化下的数据保存方法 | |
CN113327159A (zh) | 一种银行端助贷交易系统及其方法 | |
CN112785280B (zh) | 一种基于二级法人模式的推送存款产品的装置 | |
CN112348500A (zh) | 一种医疗支付闭环管理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |