auxmoney：德国最大贷款市场的事件驱动信贷
在 auxmoney.com 担任首席架构师，主导信贷评估链路建设--Kafka 骨干、AI/LLM 自动化嵌入，以及在严肃监管框架下运行的 fintech 基础设施，规模和合规压力都是真的。
先把结局说清楚：这个业务单元在 2025 年 4 月因战略重组而关闭。不是性能问题，不是技术故障。Fintech 就是这样奇怪—你可以交付出色的基础设施，然后眼睁睁看着组织架构在你脚下折叠。灯熄灭的时候，系统运行得好好的。这个区别对我很重要，我愿意直说，而不是把它埋在文字里。
好了。现在说真正有意思的部分。
auxmoney 是什么
auxmoney 是德国最大的贷款市场—一个连接私人借款人与机构及零售投资者的点对点借贷平台。规模是真实的，监管框架是严肃的。BaFin、GDPR、消费者信贷指令、德国借贷法—这些框架的每一条在你大规模做信贷决策时都会用不同方式咬你。
我以首席软件工程师和架构师的身份加入。这份工作是 auxmoney 所说的「打船长」：高度亲自下场写代码，不只是在白板上画框。公司期望我对系统的理解深到能改变它，而不只是 review 别人的改动。这个区分很重要，也常被低估。没有扎根于代码实际运行方式的架构，是小说。
信贷评估链路
借款人提交申请。那份申请不是数据库里一行等待 cron job 的记录。它立即就是一个事件—下游的一组服务已经在等着它了。信用评分链路、欺诈检测层、监管报告钩子、合作贷款方路由逻辑—每个都有自己的域，每个都有自己的故障模式，要求是它们互不阻塞。
顺利路径要能跑通。不顺路径—信用局调用超时、凌晨 3 点被限流的合作贷款方 API、返回了模糊状态的合规检查—所有这些都必须处理，而且不让借款人知道发生了任何事。
Kafka 是骨干，因为你需要持久性、重放和独立的消费者进度。信用局调用失败？消费者从已提交的 offset 以干净状态重试。一个下游服务有 bug，你需要重放三天的事件？倒回消费者。你在接入一个新的合作贷款方，它需要处理已经发生过的事件？再次重放。队列会忘记，Kafka 会记住。在金融系统里，「我忘了」不是可接受的故障模式。
监管可解释性不是可选项，它就是产品
这是塑造欧盟 fintech 每一个架构决策的东西，也是会议演讲系统性低估的东西。
每一个信贷决策—每一次贷款报价、每一次拒绝、每一次额度调整—都必须是可解释的、可归因的、可重现的。不是锦上添花，是法律要求。如果监管机构问「这个借款人为什么在这个日期被拒绝」，答案不能是「我们跑了一个模型，模型说不行」。你需要能重建出精确的输入、精确的模型版本、精确触发的规则，以及如果存在的话精确的人工介入移交点。
这改变了事件处理链路的设计方式。事件是不可变的。某些情况下，元数据比载荷还多：谁发起了这个决策，咨询了哪个模型版本，触发了哪条规则，决策时输入数据是什么样的。所有这些都要保存多年。在 Kubernetes 上，这意味着 exactly-once 消费语义、幂等处理器、以及被真正监控着的死信队列。问我见过多少个死信队列被当作只写存储。答案是太多了。
把 AI/LLM 自动化放进受监管链路
模型不是最难的部分。让 LLM 自动化通过合规审查、进入生产信贷链路、在受监管的金融环境里—那才是最难的部分。
能力确实在那里。现代 LLM 在文件理解、非结构化输入的结构化提取、分类方面是有用的。它们对贷款申请大量产生的东西很有用：是 PDF 的收入证明、是扫描件的雇佣证明、需要与外部信号核对归一化的自报数据。
治理才是工作。信贷工作流里的模型调用不是原始 API 调用。它是一个版本化的、有日志的、可审计的调用，使用了固定到特定模型版本的稳定 prompt 模板，输出和决策记录一起存储，作为审计轨迹的一部分。LLM 变成了可审计链路里的一个组件。你不是在调用它然后祈祷。你把它的输出当作一个有文档、可解释的决策过程里的一个信号。这比大多数团队在消费者 app 里做的更保守。理当如此。风险不同。
真正有意思的工程在集成接缝处：LLM 输出在进入决策路径前如何验证，置信度阈值如何控制自动 vs. 人工审核，模型版本钉选如何与 event schema 版本控制的其他部分互动。没有任何教程涵盖这些。它在抽象架构遇到具体合规要求的地方。
在运行了十年的代码库里「打船长」
「打船长」不是头衔，是工作方式的描述。手在代码里，不只是在文档里。
在一个运行了十年的 fintech 代码库里，这意味着导航真实存在的东西。Kubernetes 迁移之前的 PHP 服务。Kafka 采用之前的 Java microservices。上个季度某人交付的新工具。这些不是应该为之羞耻的遗留问题—它们是一个已经为真实借款人做了多年真实信贷决策的系统里积累的投资。你既不能无视它们，也不能这个季度把它们全重写一遍。
所以你在边界处构建。你从遗留系统的边缘发布域事件。你在 Kafka topic 层面定义合同，让每个服务拥有自己的实现。那个作为借款人状态真实来源的 PHP 服务这个 sprint 不会被替换—它正在被包裹在一个 event 接口里，让新的信贷评估链路可以从它消费而无需知道它的内部结构。这是唯一真正能落地的那种迁移方式。
所有东西下面是 AWS：EKS 跑 Kubernetes 工作负载，MSK 跑托管 Kafka，RDS 跑需要关系型的关系型状态。基础设施不复杂，问题在域和监管里，不在技术栈里。
这种工作留给你的东西
做对的借贷基础设施是我工作过的技术上最严格的领域之一。高交易量、硬延迟要求、监管可解释性和真实金融后果的组合，产生了一种我在其他地方没有见过如此一致地被复制的工程纪律。
业务单元关闭了，就关了，这是商业。组织架构变化之前系统在做什么是另一个问题，答案是：运行良好。
我目前在 Fulcrum 上做开源工作—一个 local-first 的 agent 控制面—也在接 fintech 和金融基础设施方面的咨询。如果你在构建 event-driven 信贷基础设施，想专门就合规集成层交流经验，你知道怎么找到我。