auxmoney：ドイツ最大ローンマーケットプレイスのイベント駆動与信

この話がどう終わったかについて正直に言う：ビジネスユニットが2025年4月に戦略的再編の中で閉鎖された。パフォーマンスの問題じゃない。技術的な失敗でもない。フィンテックはそういうものだ—優れたインフラをリリースして、それでもorg chartが自分の下で折りたたまれるのを見ることがある。ライトが消えたとき、システムは問題なく動いていた。その区別は私には重要で、埋めるのではなく率直に言う。

では。本当に面白い部分へ。

auxmoney とは何か

auxmoney はドイツ最大のローンマーケットプレイス—民間の借り手を機関投資家と個人投資家につなぐP2Pレンディングプラットフォームだ。スケールは本物だ。規制の包絡線は厳しい。BaFin、GDPR、消費者信用指令、ドイツ貸付法—これらのフレームワークのそれぞれが、ボリュームで与信判断をするときに異なる噛み方をする歯を持っている。

プリンシパルソフトウェアエンジニア兼アーキテクトとして参加した。仕事は auxmoney が「Playing Captain」と呼ぶもの：ホワイトボードに箱を描くだけでなく、コードベースに非常に深く関わる。システムを変えられるくらい深く理解することが期待されていた、ただ他の人の変更をレビューするだけでなく。この区別は重要で過小評価されている。実際にコードがどう動くかに根ざしていないアーキテクチャはファンフィクションだ。

与信審査パイプライン

借り手がアプリケーションを提出する。そのアプリケーションは順番を待つデータベースの行じゃない。それは即座にイベントになり、ダウンストリームサービスのクラスターがすでに待っている。与信スコアリングパイプライン。不正検出レイヤー。規制報告フック。パートナーレンダールーティングロジック。それぞれが独自のドメインで、独自の障害モードを持ち、互いにブロックしないことが要件だ。

ハッピーパスは動かなければならない。アンハッピーパスも—与信機関の呼び出しタイムアウト、午前3時にスロットリングしたパートナーレンダー API、曖昧なステータスを返したコンプライアンスチェック—これらすべてが借り手に何も起きたように見せながら処理されなければならない。

Kafka がバックボーンなのは、耐久性、リプレイ、独立したコンシューマー進捗が必要だからだ。与信機関の呼び出しが失敗した？コンシューマーはコミット済みオフセットからクリーンな状態でリトライする。バグを持つダウンストリームサービスのため3日分のイベントをリプレイする必要がある？コンシューマーを巻き戻す。すでに発生したイベントを処理する必要がある新しいパートナーレンダーをオンボーディングしている？再びリプレイ。キューは忘れる。Kafka は覚えている。金融システムでは「忘れた」は許容できる障害モードじゃない。

規制上の説明可能性はオプションじゃない。それが製品だ

これは EU フィンテックのすべてのアーキテクチャ上の決断を形作るものであり、カンファレンストークが系統的に過小評価するものだ。

すべての与信判断—すべてのローンオファー、すべての拒否、すべての上限調整—は説明可能で、帰属可能で、再現可能でなければならない。あったらいいなではなく、法的要件として。規制当局が「この借り手はこの日付にどうして拒否されたか」と尋ねた場合、答えは「モデルを実行してモデルがノーと言った」ではダメだ。正確な入力、正確なモデルバージョン、発火した正確なルール、もしあれば正確な人間のハンドオフポイントを再構築できる必要がある。

これがイベントパイプラインの設計方法を変える。イベントはイミュータブルだ。ケースによってはペイロードよりメタデータの方が多い：誰が判断を開始したか、どのモデルバージョンが参照されたか、どのルールが発火したか、判断時点でインプットデータがどう見えたか。それらすべてが何年も残る。Kubernetes上でこれはexactly-onceコンシューマーセマンティクス、冪等ハンドラー、そして実際にモニタリングされているデッドレターキューを意味する。書き込み専用ストレージとして扱われているデッドレターキューを何個見たか聞いてほしい。答えは多すぎる。

規制されたパイプラインで AI/LLM オートメーションをリリースする

モデルは難しい部分じゃない。LLM オートメーションをコンプライアンスレビューに通すこと、本番の与信パイプラインで、規制された金融環境で—それが難しい部分だ。

能力は本当にある。モダンな LLM はドキュメント理解、非構造化入力からの構造化抽出、分類に役立つ。ローンアプリケーションが大量に生成するものに役立つ：PDF の収入証明書、スキャンの雇用証明書、外部シグナルと照合して正規化する必要がある自己申告データ。

ガバナンスが仕事だ。与信ワークフローでのモデル呼び出しは生の API 呼び出しじゃない。特定のモデルバージョンにピン留めされた安定したプロンプトテンプレートを持ち、出力が監査証跡の一部として判断記録と一緒に保存された、バージョン管理された、ログに記録された、監査可能な呼び出しだ。LLM はきちんと監査できるパイプラインのコンポーネントになる。呼び出して期待するだけじゃない。その出力を文書化された説明可能な判断プロセスの一つのシグナルとして扱う。これはほとんどのチームがコンシューマーアプリでやることよりも保守的だ。そうあるべきだ。ステークスが違う。

面白いエンジニアリングは統合のつなぎ目にある：LLM の出力が判断パスに入る前にどう検証されるか、信頼度閾値がどう自動と手動レビューをゲートするか、モデルバージョンピン留めが残りのイベントスキーマバージョニングとどう相互作用するか。これらは何のチュートリアルにも書いていない。抽象的なアーキテクチャが具体的なコンプライアンス要件に出会う場所にある。

10年物のコードベースで Playing Captain

「Playing Captain」はタイトルじゃない。どう働くかの説明だ。ドキュメントだけじゃなく、コードの中に手を入れる。

10年動いてきたフィンテックのコードベースでは、実際に存在するものをナビゲートすることを意味する。Kubernetes マイグレーション前の PHP サービス。Kafka 採用前の Java マイクロサービス。誰かが前四半期にリリースした新鮮なユーティリティ。これらは恥ずべきレガシー問題じゃない—何年も実際の借り手に実際の与信判断をしてきたシステムへの累積投資だ。無視もできないし、今四半期にすべて書き直すこともできない。

だから境界で構築する。レガシーシステムのエッジからドメインイベントを発行する。Kafka トピックのレベルでコントラクトを定義して、各サービスが実装を所有させる。借り手状態の真実の源泉である PHP サービスは今スプリントで置き換えられない—それは新しい与信審査パイプラインが内部を知らずにコンシュームできるイベントインターフェースでラップされる。実際にリリースされる唯一の種類のマイグレーションはそれだ。

下にあるのは全部 AWS：Kubernetes ワークロードに EKS、マネージド Kafka に MSK、リレーショナルである必要がある状態に RDS。インフラはエキゾチックじゃない。問題はドメインと規制にある、スタックじゃなく。

この種の仕事が残すもの

正しく行われたレンディングインフラは私が働いた中で技術的に最も徹底したドメインの一つだ。高いトランザクションボリューム、厳しいレイテンシ要件、規制上の説明可能性、そして実際の金銭的結果の組み合わせが、ほかの場所で同じくらい一貫して見たことのないエンジニアリング規律を生む。

ビジネスユニットが閉じたとき、閉じた。それがビジネスだ。org chart が変わる前にシステムが何をしていたかは別の問いで、答えは：問題なく動いていた。

現在は Fulcrum—ローカルファーストのエージェントコントロールプレーン—のオープンソース作業をしていて、フィンテックと金融インフラの会話に利用可能だ。イベント駆動与信インフラを構築していてコンプライアンス統合レイヤーについて話したいなら、どこで見つけられるかはわかるだろう。