概要

  • McCracken は、支払条件、コベナンツ(誓約条項)監視、担保データ、ワークフロー証跡、会計出力、承認、ポートフォリオ報告が貸手の行動に十分合致する、受け入れ可能な商業ローンサービシング記録を通じて評価されるべきである。
  • マサチューセッツ州ビレリカに拠点を置く商業融資ソフトウェアの専門企業であり、公的な McCracken の証拠は、同社の STRATEGY 製品がサービシング、ローン管理、会計、投資家報告、資産管理、ワークフロー、ルール、レポート、保険コンプライアンス、データ移行、リスク格付をカバーしていることを示している。
  • 最も強力な公的採用シグナルは、CHFA、Cinnaire、Gantry、BridgeInvest に関する顧客発表であり、いずれも業務自動化、ポートフォリオ管理、旧システムからの移行、リスク低減、またはホスト型運用を中心に据えたもので、一般的なフィンテックの新奇性ではない。
  • 主な不確実性の境界は重要である。公的ソースは顧客構成、欠陥率、導入コスト、データ移行品質、SOC 報告の詳細、リカバリテスト、サポートチケット、借手の成果を公開していないため、購入者は STRATEGY を記録のシステムとして扱う前に、直接のデューデリジェンスを実施する必要がある。

真の製品は記録の正しさ

商業ローンサービシングソフトウェアは、金融ラベルのついたワークフローソフトウェアと誤解されやすい。それは浅薄な見方である。商業用および集合住宅ローンにおいて、製品とはローン記録が時間とともに受け入れられることである。貸手は、借手の債務額、どのトランシェまたは準備金口座が変更されたか、コベナンツが有効か、担保情報が信頼できるほど新しいか、承認は行われたか、会計仕訳は生成されたか、投資家に何を報告すべきか、ポートフォリオ報告がその基礎となるローンの運営実態と整合しているかを把握しなければならない。

これが McCracken Financial Software を評価する正しい問いである。同社は消費者ローンアプリ、借手マーケットプレイス、信用スコアリングモデル、銀行勘定系を販売しようとしているわけではない。公式サイトは、STRATEGY を商業用および集合住宅ローンサービシング・資産管理システムとして提示し、McCracken は商業ローンのライフサイクル全体にわたって借手、投資家、規制当局のニーズを支援する統合アプリケーションを説明している。ホームページによれば、STRATEGY は銀行、保険会社、プライベートレンダー、事業目的レンダー、フィックス&フリップ建設レンダー、ブリッジレンダーなど、18万件以上のローンを管理している。製品ページには、ローン管理や会計から、投資家報告、資産管理、ビジネスプロセス管理、ルール、レポート、保険コンプライアンス、建設ローンソフトウェア、データ移行、リスク格付にまで及ぶプラットフォームが描かれている。

したがって、購入者の問いは「ポートフォリオダッシュボードはあるか」よりも正確であるべきだ。多くのシステムはダッシュボードを表示できる。複雑な商業ローンが数カ月から数年にわたるサービシング活動の後も状態を保持できるシステムははるかに少ない。有用な問いは、アクションが一旦受け入れられた後、異なるチームが信頼できる永続的なポートフォリオ記録の一部になるかどうかである。支払変更は正しい残高、会計出力、借手通知を更新すべきである。コベナンツ例外はサービシングワークフロー、リスク格付コンテキスト、管理レポートで可視化されるべきである。物件検査やレントロールはアナリストのスプレッドシートだけに存在すべきではない。建設ローンの引出要求は予算、ワークフロー、承認コンテキストを伴うべきである。レガシーシステムからの移行は、サービス担当者にどのローン条件、エスクロー詳細、支払履歴が信頼できるか疑問を抱かせてはならない。

この受け入れられた記録のテストは、記事を公平な境界内に留める。McCracken の公開資料は自動化、効率性、セキュリティ、ホスト型運用、顧客成功について幅広い主張をしている。これらの主張は重要だが、顧客の実装成果物によって裏付けられない限り、ベンダー主張に過ぎない。公開情報は、システムが何を行うと主張しているか、一部の顧客が自らの採用をどう位置づけたかを示している。プライベートなローンファイル、元帳照合、ユーザーアクセスレビュー、サポートチケット、災害復旧テスト、実装作業明細書、本番稼働後の欠陥ログは示されていない。最も強力な公的結論は、McCracken が商業ローンサービシングソフトウェアの専門プロバイダーであり、その製品領域が貸手が必要とする運用コントロールと密接に合致していることである。すべての STRATEGY 顧客がクリーンなサービシング記録とより低い運用リスクを持っているという強い主張には、公的でない証拠が必要である。

アイデンティティ、ブランド、範囲

ここで評価する企業は McCracken Financial Software である。公的証拠は McCracken Financial Solutions や McCracken Financial Solutions Corporation という名称も使用している。現在の公式ウェブサイト mccrackenfs.com は、マサチューセッツ州ビレリカの8 Suburban Park Drive に McCracken Financial Solutions Corp.を置き、McCracken を商業融資業界向けソフトウェアプロバイダーとして提示している。McCracken が姓、地名、他コンテキストでの歴史的企業名としても存在するため、公的ブランド境界は重要である。本記事はビレリカに拠点を置く商業融資ソフトウェア企業とその STRATEGY 商業ローンサービシングシステムに関するものであり、貸手、借手、学区、公務員、無関係な McCracken 事業体に関するものではない。

「Financial Software」という命名には歴史的な理由がある。公開ウェブ上の痕跡はまだ McCracken Financial Software Inc.を参照している。2001年の Deseret News の報道は、McCracken Financial Software が FASRE Field Services から資産を取得したと報じ、マサチューセッツ州ビレリカに拠点を置くと説明した。検索アクセス可能な S&P や Fitch の古いサービサー評価のスニペットも McCracken Financial Software Inc.と McCracken Strategy プラットフォームに言及している。これらの歴史的シグナルは現在の公式サイトを上書きすべきではないが、この記事が McCracken Financial Software の名称を使いつつ、アクティブブランドが McCracken Financial Solutions を提示している理由を説明する助けになる。

公式の「Our Company」ページによれば、McCracken は30年近く商業融資ソリューションを提供しており、STRATEGY を主力製品とし、幅広い商業ローンの種類に対応する会計、サービシング、資産管理機能を備えている。同ページは商業ポートフォリオ監視のための統合ワークフローツールやビジネスルールロジックを強調している。フッターとサイトコピーは銀行、保険会社、住宅ローン銀行、準政府機関の顧客を説明している。公開調査中に見つかった LinkedIn の企業プロフィールは、McCracken を1991年設立、ビレリカ本社、非公開のソフトウェア開発企業とし、従業員数51~200名、専門分野は商業融資、商業銀行、商業不動産、フィンテック、商業サービシング、商業ローンソフトウェア、商業ローンシステムとしている。こうしたディレクトリ的シグナルはアイデンティティ把握に有用だが、製品性能には有用ではない。

アクティブな製品範囲は汎用的な「フィンテック」よりも狭く有用である。McCracken は STRATEGY を商業用および集合住宅ローンサービシングと資産管理のシステムと説明している。製品ページは商業銀行、保険会社、住宅ローン銀行、政府支援機関(GSE)、サービサーをターゲットユーザーとして挙げている。また、大規模・小規模サービサー向けに構築され、ローン単位の価格設定で追加料金なしの無制限ユーザー、柔軟な実装とトレーニングオプションを提供するとしている。言い換えれば、同社は商業ローンを既に組成、購入、サービシング、管理している機関向けに、運営記録インフラを販売している。

この区別は商業的に重要である。ある貸手は借手を見つけたり、ローンを組成するか判断するために McCracken を購入するのではない。ローン活動開始後の管理およびリスク記録を保持するために購入するのだ。価値はクロージング後に蓄積される日々の状態にある。連絡先役割、ローン条件、トランシェ、エスクロー、準備金、投資家送金、物件パフォーマンス、コベナンツ、例外、保険要件、ユーザータスク、レター、レポート、会計出力である。これらの記録が誤っていれば、インターフェースは問題にならない。記録が受け入れられていれば、ポートフォリオビューとワークフロー自動化は信頼できるものになる。

STRATEGY が保持すると謳うもの

McCracken の詳細な STRATEGY 機能ページは、製品が管理すると主張するデータとプロセスのカテゴリーを列挙しているため、非常に有用である。ローン管理では、顧客事業体が一度入力され、連絡先情報と複数住所が追跡でき、役割を割り当て、事業体を複数のローンに関連付け、エクスポージャーを表示できるとしている。また、1つのローン内で複数の貸出タイプ、異なる条件のトランシェ、トランシェ間の資金移動を処理できるとしている。ローン情報については、現在の状態スナップショット、通貨指標、固定金利と変動金利、リボルビング残高、ホールドバックとバイダウン、複数の支払頻度、複数の支払タイプ、元本均等返済と金利のみの構造、ネガティブアモチゼーション、複数の金利計算オプションを挙げている。

このリストが重要なのは、商業ローンサービシング記録の最低限の密度を示しているからである。商業不動産ローンは単に元本、金利、満期だけではない。保証人、借手連絡先、担保物件、準備金口座、保険債務、エスクロー処理、財務諸表要件、レントロール要件、物件検査、変動金利条項、引出規則、シンジケーションや投資家送金、延滞利息、繰延利息、期限前返済プレミアム、手数料、不良債権処理を含み得る。これらの詳細をモデル化できないシステムは、スプレッドシートの薄いラッパーにすぎない。

同じ McCracken のページには、期日管理、延滞料金、変動ローン見直し、支払変更、保留中の条件変更のためのビジネスカレンダーロジックが記載されている。金銭的および非金銭的デフォルトに対する延滞利息サポート、繰延利息追跡、繰延収益・費用メソッド、ペイオフ見積、クロス担保化、クロスデフォルトローン、期限前返済プレミアム、イベントベースの手数料もリストされている。ローン会計機能として、総勘定元帳トランザクション明細、不良債権、コントラ会計、債務免除、償却が含まれる。STRATEGY 概要ページでは、会計エンジンが GAAP、STAT、税務会計基準を用いて総勘定元帳エントリを作成し、企業の総勘定元帳システムに送付可能な日次取引記録を生成するとしている。

支払状態は、受け入れられた記録のテストが容赦ないものになる場面である。サービス担当者は、支払充当順序、延滞料金、延滞利息、繰延、エスクロー、準備金、投資家送金を独立したウィジェットのように安全に扱うことはできない。1つの計算が変われば、下流の記録が動く。延滞料金ルールの失敗は借手通知を変える可能性がある。繰延利息処理は残高報告に影響し得る。不良債権には異なる会計出力が必要になるかもしれない。当日電信送金やロックボックス処理は固有の運用依存関係を持ち込む。McCracken の公開機能リストはすべての顧客構成が正しいことを証明するわけではないが、STRATEGY が商業サービシングチームが実際に保持しなければならない種類の状態を中心に設計されていることを示している。

セキュリティと管理の主張も製品レベルで現れる。詳細機能ページには、二要素認証、ユーザーおよびグループ別アクセス、ユーザー・グループ画面権限、SOC 1準拠が記載されている。これらは貸手にとって意味のある用語だが、それだけでは不十分である。購入者は、該当する場合の実際のレポート範囲、信頼サービス基準または管理目標、補完的ユーザー事業体管理、サブサービス組織の扱い、テスト期間、例外、改善策を求めるべきである。公開マーケティングはデューデリジェンスを支援するが、規制対象金融機関がホスト型サービシングソフトウェアを重要システムとして扱う前に必要な管理証拠を代替することはできない。

コベナンツの真実こそが運用面である

本記事の角度はコベナンツに焦点を当てている。なぜなら、コベナンツの状態がサービシングプラットフォームが本当に機能しているかどうかを明らかにするからである。コベナンツは飾りのフィールドではない。それは、定期的な財務諸表、DSCR、レントロール、物件検査、保険証憑、準備金積立、承認または報告を必要とし得るローン契約上の約束または条件である。コベナンツ記録が弱い場合、貸手はローンが健全か、借手が情報提出に遅れているか、免除が承認されたか、リスク格付が依然として最新の証拠を反映しているかを把握できないかもしれない。

McCracken の公開ページは繰り返しこの監視問題を指し示している。STRATEGY 概要では、本システムが借手通信から投資家報告に至るサービシングを追跡し、支払条件、金利計算、エスクロー支払、投資家報告、コベナンツコンプライアンスを含むとしている。また、基礎となるビジネスルールが期日やデータ状態を監視し、適切な担当者に警告するか、ローン管理に必要なステップを開始すると述べている。詳細機能ページには、財務諸表、評価、物件検査、レントロールに関するポートフォリオ管理フィールドが追加され、ローンコベナンツ管理を自動化する「トリガー管理」が別にリストされている。ルールエンジンは、リスク指標とコベナンツに関する自動ポートフォリオ監視と記述されており、アクションには警告、メール、レター、またはプロセス開始が含まれる。

これは正しい製品文法である。コベナンツの真実は、「パス」または「フェイル」と言うテーブルセル以上のものに依存している。それは、証拠、日付、計算式、ポリシー閾値、レビューア、承認、タスク履歴、借手通信、経営陣が見るレポートに依存している。あるコベナンツがまだ到着していないレントロールに依存している場合、その不在自体が状態である。財務諸表が受領されたがレビューされていない場合、システムは受領と承認を区別すべきである。コベナンツ免除が承認された場合、その記録は誰が承認したか、何が変わったか、期間、フォローアップ要件を示すべきである。

規制参照が、この問題が単なる貸手の好みではない理由を補強している。FDIC のローン審査マニュアルは、効果的なローン審査システムを、信用の弱点、トレンド、ポリシー遵守、ポートフォリオ品質を識別するメカニズムと説明している。また、正確でタイムリーな信用格付をローン審査の主要構成要素と強調している。OCC の商業不動産融資ハンドブックは、管理システムを、経営陣がパフォーマンスを測定し、リスク決定を行い、プロセス有効性を評価するために使用する機能と情報システムと定義している。それによれば、CRE 管理システムには通常、リスク管理、信用リスク審査、サードパーティリスク管理、品質保証、品質管理、内部監査が含まれる。連邦準備制度がホストする CRE ローン条件変更とワークアウトに関するポリシーステートメントは、健全な慣行として、財務情報および担保情報の更新と評価、適切なリスク格付フレームワークの維持、ローン条件変更の適切な追跡と会計を含むと述べている。

これらの公開参照のいずれも McCracken を保証するものではない。それらは購入者の問題を説明している。貸手の記録システムは、機関がタイムリーでレビュー可能な信用管理の証拠を生成するのを支援しなければならない。McCracken にとって、価値提案が最も強力なのは、STRATEGY のルール、ワークフロー、ドキュメント、物件記録、リスク格付、レポートが、悪化が遅すぎて気づかない前にコベナンツ状態を見える化する場合である。リスクは、貸手が洗練された製品を導入しながら、コベナンツロジック、例外メモ、財務諸表レビューをサイドスプレッドシートで保持することである。その場合、製品だけが失敗したわけではなく、運用モデルが受け入れられた記録を権威あるものにできなかったのだ。

支払、会計、投資家の状態

2つ目の困難なテストは支払状態である。商業サービシングチームは、単に入金があったかだけでなく、どのように適用されたか、どのトランシェに影響したか、手数料や延滞料金は課されたか、どの金利計算が適用されたか、エスクローや準備金のポジションは変わったか、どの会計仕訳が生成されたか、どの投資家や参加者に支払うべきかを知る必要がある。ダッシュボードはこの複雑さを隠蔽し得る。サービシング記録はそれができない。

McCracken の製品ページは、デューデリジェンスの質問を組み立てるのに十分な詳細を提供している。STRATEGY は、ロックボックス、ACH および事前承認支払、電信処理と小切手作成、コルレスポンデントサービシング、取引レポート、振替伝票、貸倒準備金償却を列挙している。税金と保険のエスクロー処理、複数の税務サービス会社サポート、割引スケジュール、強制加入および包括保険アレンジメント、損失追跡、複雑なエスクロー分析を挙げている。ユーザー定義の準備金タイプ、DDA レベルでの口座追跡、上限残高を持つ準備金についても記載している。さらに、ローン別または投資家別の複数の送金方法、政府支援機関(GSE)、内部またはプライベート投資家、債券処理、元本準備金と償還、証券化およびシンジケートローン向け CREFC 報告、支払金額の計算と送金を含む投資家処理機能もリストしている。

これらの機能は、商業ローンサービシングソフトウェアがスティッキーである実際的な理由を物語っている。一度、貸手の取引履歴、会計出力、投資家報告、エスクロー詳細、準備金ロジック、借手通信が1つのプラットフォーム内に存在すると、そのプラットフォームを置き換えることは単純なソフトウェア交換ではない。顧客は単に画面を移行するのではない。それは、資金、債務、決定の履歴を移行することである。移行は、残高、支払適用ロジック、未収手数料、金利方式、エスクロー残高、準備金口座、投資家配分ルール、報告コード、監査履歴、例外事項を保持しなければならない。だからこそ、商業的な検討事項には、サブスクリプション価格だけでなく、移行リスク、トレーニングコスト、スプレッドシートへの逆戻りが含まれる。

McCracken の2021年7月の STRATEGY 20発表は、その状態の一部に直接対処した。リリース発表では、当該バージョンがポートフォリオのより迅速な移行、SOFR 計算のサポート、手動データ入力の削減、シンジケートローンの追加を含む機能を提供すると述べた。また、ポートフォリオ全体での FEMA 災害アラート、関係性可視化、エスクロー、税務、投資家処理、データ抽出、保険コンプライアンス、借手問合せ管理、当日電信送金も挙げた。McCracken は、SOFR の影響について代替参照金利委員会と協力し、変動金利ローンに関する顧客ワーキンググループを作成してフィードバックを収集したと述べた。この発表はベンダー発信だが、ベンチマーク金利移行、災害リスク、投資家ワークフロー、ポートフォリオ移行といった実際のサービシングイベントに対応した製品開発を示している。

購入者にとって、受け入れパッケージは具体的であるべきだ。支払テストには、通常支払、一部支払、延滞支払、期限前返済、支払変更、繰延、延滞利息、ペイオフ見積、準備金、エスクロー、投資家送金を含めるべきである。会計テストでは、システムの仕訳を企業の総勘定元帳と照合する必要がある。投資家報告テストでは、合計、タイミング、配分が契約要件と一致することを示さなければならない。移行テストでは、誤った前提を見つけるのに十分な深度で、元の記録と変換後の記録を比較する必要がある。借手通信テストでは、通知、レター、ポータル情報を同じ元となる記録に結びつけるべきである。そうして初めて、貸手はサービシングアクションが受け入れられたポートフォリオ記録になったと言える。

担保とポートフォリオのコンテキスト

商業用および集合住宅サービシングは、担保監視でもある。担保は、物件、複数物件、建設プロジェクト、リース、レントロール、物件検査、保険証券、不動産鑑定、課税状況、または組成後に変化するその他の証拠であり得る。静的なローン記録は、クロージング時に何が承認されたかを答えうる。サービシングプラットフォームは、担保が依然として信用ストーリーを支えているかどうかに答えなければならない。

McCracken のポートフォリオ管理と資産管理機能は、この運用面に対処している。STRATEGY 概要では、クラウドベースのポータルが基礎となる担保のパフォーマンスを保存、分析、報告すると述べている。また、本システムが財務諸表やレントロール、物件検査の提出を要求し、受領を追跡し、保存するとともに、スプレッドシートや内製システムへの依存を低減するとしている。詳細機能ページには、詳細な物件情報、複数ローンからの物件の割り当てと閲覧、物件パフォーマンスと状態情報、関係性およびエクスポージャーの可視化、自然災害地域内の物件のリアルタイム識別、評価、物件検査、レントロール、鑑定データ保存、ルール違反が記載されている。

これらの事実が重要なのは、担保データのドリフトが本記事で既知の失敗モードの1つだからである。最終の検査が古い場合、評価が更新されていない場合、レントロールが欠落している場合、保険要件が未検証の場合、物件が自然災害地域に暴露されておりタスクが開始されない場合、ローン記録の信頼性は低下する。リスクは必ずしも即時のデフォルトではない。リスクは、経営陣が、基礎となる証拠が有用性を失うほど古くなったポートフォリオビューに基づいて行動することである。

保険コンプライアンス製品はその点を補強する。McCracken の製品リストには、商業保険証券およびリスク要件をスキャン、比較、監視するクラウドベースの保険審査業務が記述されている。STRATEGY 詳細ページでは、保険コンプライアンスがポリシーをスキャン、比較し、リスク要件に対して監視でき、ワークフローを含み、Fannie Mae、Freddie Mac、FHA の要件が事前ロードされているとしている。2019年の McCracken ニュース項目では、保険アプリケーションがパッケージ、スタンドアロン、包括の各ポリシーを扱うと説明した。これらの主張は機能証拠としては最も強い。購入者は依然として、文書がどのようにキャプチャされるか、例外がどのように処理されるか、ポリシー要件がどのようにマッピングされるか、誤ったマッチングがどのようにレビューされるか、証拠がどのように保持されるかを確認する必要がある。

BuildRite は建設融資に関して担保の問いを拡張する。McCracken は BUILDRITE を、商業建設ローンを一元化し、商業建設予算プロジェクトを管理し、複数の資金ソースをキャプチャし、顧客定義の予算テンプレートをサポートし、予算、引出、変更指示のためのワークフローをサポートし、スプレッドシートから行項目をインポートする建設ローンソフトウェアと説明している。製品ページは、スプレッドシートを排除することで各ユーザーが年間260時間節約できると主張している。この数字は企業の主張だが、ワークフローのターゲットは明確である。建設ローンサービシングは、単に残高の問題ではない。引出、予算、変更指示、検査、資金ソース、承認、プロジェクト状態の可視化が関わる。

したがって、担保コンテキストは、McCracken が一般的なローン元帳と置き換え可能でない主な理由の1つである。製品の公開面は、担保証拠、リスク指標、運用作業をローン記録に結びつけておくように設計されている。そこからポートフォリオ管理が生まれる。購入者は、華やかな地図や物件画面を証拠として受け入れるべきではない。担保証拠が欠落、陳腐化、矛盾、ポリシー外の場合に、その記録が適切なフォローアップを強制するかどうかを問うべきである。

ワークフローの証拠と例外のコスト

ワークフローは、それが証拠を残す場合にのみ価値がある。ローンサービシングチームは、システムを通じてタスクをルーティングしても、承認、メモ、文書、例外が受け入れられた記録の外に置かれると、運用上の真実を失う可能性がある。McCracken の公開機能セットは、ワークフローをビジネスルール、プロセス管理、メモに繰り返し結びつけているが、これは原則的に正しいアーキテクチャである。

STRATEGY 概要では、Process Manager が顧客がほとんどまたは全く McCracken の支援なしにプロセスとタスクを定義できるようにし、ビジネスルールと組み合わされたプロセスが、ルールが必要性を認識したときに自動的に開始できるとしている。また、統合メモアプリケーションが会話を維持し、プロセス全体を通じて文書を保存し、実行された作業の物語を作り出すと述べている。詳細機能ページでは、Process Manager が作業をスタッフやベンダーに割り当ててルーティングし、リマインダーやチックラーを排除し、ワークフローを IT 支援なしで設定できるとしている。ルールエンジンは、ポートフォリオを監視し、リスク指標とコベナンツを識別し、警告、メール、レター、プロセス開始をトリガーできる。

この設計は、商業サービシングが例外に満ちているために重要である。不足している財務諸表、遅延した税金請求、保険の不備、コベナンツ違反、建設引出に関する質問、変動金利の見直し、借手からの問い合わせ、ペイオフ要求、自然災害エクスポージャー、不良債権イベントには、異なるチームが必要になるかもしれない。失敗モードは、必ずしも誰も問題を見なかったことではなく、問題が見られ、メールで議論され、表計算で先送りされ、口頭で承認され、または永続的なコンテキストなしに解決されることである。次回の監査、リスクレビュー、ポートフォリオ会議がやって来たとき、貸手は何が起こったかを再構築できない。

規制参照は、なぜこれが重要なのかを再び示している。OCC CRE ハンドブックは、内部監査レビューにはしばしば、信用とローンドキュメンテーションのサンプル、現金支出、ペイオフ、償却、経営報告が含まれ、取締役会や上級管理職向け報告の正確性と適時性のテストを含むと述べている。FDIC ローン審査マニュアルは、ローン審査システムが経営陣と取締役会にポートフォリオ品質の客観的評価と規制報告に有用な情報を提供することが期待されていると述べている。この意味で、ワークフローの証拠は管理的なオーバーヘッドではない。それは、運営上の決定がどのようにしてレビュー可能になるかである。

購入者の受け入れテストは、厄介なケースを含むべきである。システムは、延滞料金が免除された理由を示せるか?誰がレントロールをレビューしたかを示せるか?財務諸表の要求を受領、レビュー、コベナンツ計算、承認、リスク格付に結び付けられるか?建設引出が正しい予算区分と承認経路に対して処理されたかを示せるか?借手の問い合わせが適切なレビューなしに支払状態を変更しなかったことを証明できるか?合計が基礎となるローン記録と一致し、例外が説明されている報告を生成できるか?

McCracken が適切に構成されていれば、ワークフローは例外をサービシング記録を保持する同じシステム内で可視化することによって、スプレッドシートへの逆戻りを減らすはずである。不適切に構成されていれば、ワークフローはタスクの包装紙になり、実際の証拠は引き続きメール、共有ドライブ、アナリストのノートに存在し続けるかもしれない。これが実装リスクである。製品表面は受け入れられた記録の規律をサポートしているが、規律は依然として貸手によって設計、トレーニング、実施されなければならない。

ホスト型運用とサードパーティリスク

McCracken は製品周辺のサービスも販売しており、それらのサービスはリスクプロファイルに影響を与える。公式サイトには、カスタマーサポート、ホスティング、製品開発、コンサルティングがリストされている。サポートページでは、McCracken のサポート担当者が電話またはオンライン問い合わせで支援し、継続的なユーザートレーニング、トレーニングビデオとドキュメンテーション、全国ユーザーグループ、年次カスタマーカンファレンスを指摘している。コンサルティングページには、商業融資経験を持つビジネスアナリストが、システム構成、トレーニング、テスト計画、プロジェクト管理を提供し、稼働後も新入社員トレーニング、機能実装、ビジネスプロセス設計、ヘルスチェックなどのサービスを提供すると説明されている。製品開発ページでは、McCracken のアーキテクトと開発者がソフトウェアを更新し、ユーザーグループと協力し、機能や拡張を構築し、エンタープライズ環境向けの統合や拡張を提供するとしている。

ホスティングページは、クラウドサービスのカテゴリーに特に関連が深い。McCracken は20年近いホスティング経験を持ち、Strategy アプリケーションとデータの24時間365日の可用性維持を目指している。ハードウェアとソフトウェアの保守、日次終了処理、顧客の指示に基づくアップグレード、パフォーマンス監視、災害復旧プログラム、ネットワークおよびハードウェア管理、パッチ適用、冗長システム、監視をリストしている。これらの記述は、ホスティングを偶発的な展開オプションではなく、中心的な運用主張としている。

銀行、信用組合、貸手、サービサーにとって、ホスト型ローンサービシングソフトウェアは、直接の管理上の影響を持つサードパーティ関係である。2023年の連邦官報に掲載された省庁間のサードパーティリスクガイダンスは、銀行組織がリスク管理をサードパーティ関係のリスクプロファイルと複雑性に合わせて調整すべきであり、すべての関係が同じ監視を必要とするわけではないと述べている。また、銀行組織は各関係に関連するリスクを分析し、規模、複雑性、リスクプロファイル、関係の性質に応じて監視を調整すべきであるとしている。FFIEC 資料も同様に、アウトソースされたテクノロジーサービスが、安全で健全な運営に対する機関の責任を免除するものではなく、経営陣がアウトソーシングのリスクを特定、測定、監視、軽減すべきであることを明確にしている。

これが、McCracken のホスト型サービスの主張を単なるアップタイムマーケティングとして評価できない理由である。デューデリジェンスの質問には、アクセス制御、暗号化、バックアップとリストアのテスト、リカバリ目標、脆弱性管理、パッチウィンドウ、変更管理、インシデント通知、サポートエスカレーション、監査レポート、データ保持、データエクスポート、終了支援、下請業者、統合責任が含まれる。STRATEGY がローンデータ、支払履歴、担保文書、借手通信、監査証跡をホストする場合、購入者はアプリケーション動作とホスティング運用の両方について保証を必要とする。

NIST のセキュアソフトウェア開発フレームワーク(SSDF)はソフトウェアサプライヤーの視点を加える。NIST は、セキュアソフトウェア実践を開発ライフサイクルに統合すべきであり、ソフトウェア取得者にサプライヤーとの会話のための共通語彙を与え得ると述べている。また、セキュア開発のための人とプロセスの準備、ソフトウェアコンポーネントの保護、しっかりとセキュアにされたソフトウェアの生成、脆弱性への対応を強調している。McCracken の公開ページはセキュア開発プログラムを公開していないが、アクセス制御と SOC 1準拠を挙げており、製品開発とホスト型運用について記述している。成熟した購入者は、これらの事実を、リリース管理、脆弱性対応、依存関係管理、ソフトウェア来歴、セキュアコーディング、変更承認、顧客通知に関する直接的な質問に結び付けるべきである。

採用シグナル:CHFA、Cinnaire、Gantry、BridgeInvest

McCracken の公開顧客発表は、選択されたベンダー証拠だが、顧客が解決しようとしていたとされる問題を明らかにするため、依然として有用である。それらは、ポートフォリオの状態、運用目標、または移行の問題を名指しする場合、一般的な推薦文よりも強力である。

2023年2月、McCracken は、デンバーに拠点を置くコロラド州住宅金融公庫(CHFA)が商業不動産サービシングに STRATEGY を使用すると発表した。リリースによれば、CHFA は手頃な住宅とコミュニティ開発に投資しており、コロラド州経済に297億ドル以上を投資してきた。CHFA は、ライフサイクル全般にわたるローンソフトウェアをサービシングの様々な側面で使用し、運営上の課題を改善し、ビジネスプロセスを自動化し、ローン処理と管理における従業員体験を向上させ、ホスト型システムへの移行によってテクノロジーコストを削減するとした。この発表は、単なる報告ではなく、ライフサイクルサービシングとホスト型の運営コストを強調しているため、受け入れられた記録のフレームに合致する。

2022年4月、McCracken は Cinnaire が商業不動産ポートフォリオ管理に STRATEGY を選択したと発表した。発表では、Cinnaire はコミュニティ開発金融機関(CDFI)であり、指定された Fannie Mae Affordable Lender であると説明されている。広範な調査中の優先事項は、ポートフォリオ全体の自動化を改善し、運用リスクを軽減することであり、McCracken は Cinnaire と協力して追加のリスク格付機能を開発し、ユーザー効率を高め、人為的ミスを減らし、報告を改善するとした。これは、コベナンツとリスク格付の議論に直接的に関連する。運用リスクと報告管理を中心に据えた公的な顧客ストーリーを示している。

2021年7月、McCracken は Gantry が、17,000件以上、総額160億ドルを超える商業不動産ポートフォリオ全体のサービシングを支援するために STRATEGY を選択したと発表した。発表によれば、Gantry は Norris, Beggs & Simpson の買収後、2つの異なるシステムでサービシングされている商業ローンを統合したいと考えており、STRATEGY がポートフォリオの単一システム環境への移行を支援するとした。これは、移行と統合の問題を名指ししているため、最も強力な公開事例の1つである。その問題におけるリスクはソフトウェアの購入ではなく、2つのシステム分のサービシングの真実を1つの受け入れられた記録に移すことである。

2020年11月、McCracken は、マイアミに拠点を置くプライベート不動産レンダーである BridgeInvest が商業不動産サービシング業務をサポートするために STRATEGY を選択したと発表した。発表では、BridgeInvest は既存システムをアップグレードし、CRE および集合住宅ローンとサービシングに経験のあるプロバイダーと提携したいと考えていたとしている。STRATEGY はローンのライフサイクル全体にわたるスケーラブルなエンドツーエンドのサービシングプラットフォームを提供し、より効率的に作業し、サービシング業務を改善するという顧客のコメントが含まれている。同じリリースでは、McCracken は複雑なポートフォリオと手動プロセスを抱える貸手とサービサーからの需要が高まっていると述べている。

これらの発表は市場関連性を裏付けるが、実装の問題を解決するものではない。各顧客がプロジェクト予算を満たしたか、移行例外がどのように処理されたか、稼働後にレポートが照合されたか、ユーザーがワークフローをどのように採用したか、スプレッドシートの使用が減少したか、サービシングエラーが減少したかは示されていない。慎重な購入者は、これらの発表を、同様のポートフォリオ複雑性を持つ参照先を求める理由として扱うべきであり、代替証拠として扱ってはならない。

スプレッドシート問題は技術的であると同時に文化的である

McCracken のマーケティングは、自動化とスプレッドシートや手動作業を繰り返し対比させている。これはもっともらしい。なぜなら、商業サービシングでは、主要システムが不完全、設定が遅い、またはアナリストから信頼されていない場合、しばしばサイド元帳が蓄積されるからである。しかし、スプレッドシート問題は単にシステムを購入するだけでは解決されない。それは、組織がシステムの記録が権威あるものであることに同意し、例外がその記録に戻るように作業を設計したときに解決される。

公式ブログの CRE 住宅ローンサービシング自動化に関する投稿は、自動化をローン条件変更、償却スケジュール、経営承認などのサービシングタスクの合理化と定義し、効率性、正確性、リスク管理、透明性、コスト削減といった利点を主張している。アウトソーシングと内製の比較記事では、貸手にローン量、ローンタイプ、将来のポートフォリオ展開、借手、保証人、資産レベルで追跡すべきデータ(財務、検査、コベナンツ、税、保険、準備金を含む)を考慮するよう求めている。これらの質問は、購入決定を運用設計の決定に変えるため有用である。

文化的な罠は、古いプロセスを維持したまま STRATEGY を上乗せすることである。アナリストがシステムのフィールドが不便なために依然としてコベナンツのスプレッドシートを維持し、マネージャーがワークフローが遅いと感じるために依然としてメールで例外を承認し、会計がトランザクションコードが信頼できないためにアドホックな抽出を通じて照合を続ける場合、実装はより高価な分断化の形を生むに過ぎない。製品はフィールド、ルール、プロセスマネージャー機能を提供できるが、人々が意見を異にしたときにどの記録が優先するかを、機関が決定しなければならない。

ここで McCracken のコンサルティングとサポートサービスが重要になり得る。コンサルティングページには、ビジネスアナリストが顧客のビジネスモデル、要件、日常業務の統合を理解するのを助け、テスト計画、プロジェクト管理、トレーニング、ビジネスプロセス設計、ヘルスチェックを提供できるとある。これらのサービスは STRATEGY のようなシステムにとって二次的なものではない。それらは、貸手が自らのローンタイプ、サービシングポリシー、報告ニーズ、ユーザー権限、ビジネスルール、データ移行、ワークフロー証跡、トレーニングをシステムにマッピングする方法である。リスクは実装の遅延だけではない。古いあいまいさを保存したまま迅速に実装することである。

最良の購入行動は、設定前に受け入れシナリオを作成することである。代表的なローンを選ぶ:シンプルな正常ローン、定期的な財務諸表が必要な集合住宅ローン、引出を伴う建設ローン、シンジケートまたは証券化ローン、エスクローと保険が複雑なローン、変動金利ローン、不良債権、コベナンツ例外のあるローン。次に、STRATEGY が各シナリオを現在の記録から受け入れられたサービシングアクションまで、サイド記録なしで運べるかどうかをテストする。システムが単純なケースしか通過できないなら、ダッシュボードの幅は十分ではない。

経済性:管理がロックインに勝たなければならない

商業的な問いは、商業ローンサービシングソフトウェアに機能があるかどうかではない。McCracken の公開資料は密度の高い製品を示している。問いは、よりクリーンなサービシング記録とポートフォリオ管理が、実装、統合、トレーニング、ホスティング、サポート、移行、ロックインのコストを上回るかどうかである。

価値側は理論的には明らかである。より良いサービシング記録を持つ貸手は、手動作業を減らし、例外を早期に発見し、リスク格付更新を支援し、より信頼性の高い報告を作成し、投資家送金をやり直し少なく処理し、スプレッドシート依存を低減し、借手通信を改善し、監査や信用審査のための証拠を保持できる。CHFA、Cinnaire、Gantry、BridgeInvest に関する顧客発表は、いずれも何らかのバージョンのロジックを指し示している:ライフサイクルサービシング、運用上の課題、自動化、リスク軽減、報告、単一システムへの移行、ホスト型によるコスト削減、複雑なポートフォリオへの対応。

コスト側も同様に現実的である。商業ローンの複雑さをモデル化するシステムは、すべての貸手が同じプロセスを持っているかのように実装することはできない。ローンタイプ、コベナンツ、支払適用ルール、総勘定元帳(GL)インターフェース、投資家報告、文書ワークフロー、リスク格付方法、保険要件、ユーザー権限、承認、レポートには設定が必要である。履歴データはクレンジングされ変換されなければならない。ユーザーはトレーニングを必要とする。統合はテストを必要とする。レポートは照合を必要とする。貸手は、システムが真実の記録となるように運用手順を書き換える必要があるかもしれない。この作業は、ベンダーに能力があっても高コストである。

ロックインは正直に分析されるべきである。McCracken の製品は、スプレッドシートロックインを低減しつつ、プラットフォームロックインを生み出す可能性がある。それは本質的に悪いことではない。真剣な記録システムは、それが機関の記憶の在りかとなるため、依存関係を生み出す。購入者は、その依存関係が受け入れ可能かどうかを判断すべきである。どのデータがエクスポート可能か?どのレポートが再作成可能か?文書やメモはどのように取得されるか?契約終了時に何が起こるか?API はどのように管理されているか?顧客設定はどの程度 McCracken の開発に依存しているか?後日、ホスティングの変更、新しい総勘定元帳との統合、または別のサービシングプラットフォームへの移行はどれほど難しいか?

最良の結果はゼロロックインではない。それは価値あるロックインである。すなわち、ローン記録をよりクリーンにしたために置き換えが難しいシステムであり、顧客がデータを取り出せないからではない。最悪の結果は管理的ロックインである。すなわち、移行が恐ろしいために高コストが続くが、ユーザーは実際のプロセスを別の場所で実行し続けている状態である。McCracken の公開証拠は、商業サービシング管理の中心となり得る製品を支持している。その管理がコストに勝るかどうかは、実装の規律と、再作業、手動照合、報告の不確実性の測定可能な削減にかかっている。

購入者が受け入れ前に要求すべきこと

McCracken を評価する貸手は、画面ではなく記録を中心に受け入れを定義すべきである。最初の要求は、実際のポートフォリオをカバーするローン状態モデルである。モデルは、借手と保証人の役割、担保、トランシェ、金利、支払スケジュール、手数料、エスクロー、準備金、投資家ポジション、コベナンツ、財務諸表、レントロール、検査、保険、建設予算、リスク格付、ワークフロー、レポートを含むべきである。重要なローンの種類がサイド作業なしにモデル化できない場合、そのギャップは価格付けされ、稼働前に文書化されるべきである。

2つ目の要求は移行の証拠である。レガシーシステムとスプレッドシートは、しばしば不整合なフィールド、陳腐化した値、文書化されていない手動慣習を含む。移行計画は、ソースシステム、マッピングルール、変換、未解決の例外、照合サンプル、所有者の承認を特定すべきである。サンプルは現実的な複雑性を持つローンを含むべきである。Gantry の公開発表は、複数システムからの統合が単なる抽出・ロード作業ではなく、ビジネスイベントであることを思い出させる。

3つ目の要求はコントロールの証拠である。McCracken がホスト型サービス、アクセス制御、SOC 1準拠をリストしているため、購入者は関連する監査レポート、管理範囲、例外履歴、リカバリ証拠、インシデント対応コミットメント、アクセスレビュー手順、暗号化態勢、変更管理プロセス、データエクスポート権を要求すべきである。貸手が規制対象の場合、サードパーティリスク管理は、ローンサービシングデータの重要性と統合の複雑性に応じて調整されるべきである。

4つ目の要求は会計と報告の照合である。購入者は、総勘定元帳エントリ、日次取引記録、投資家レポート、該当する場合は CREFC または政府機関関連レポート、取締役会または経営報告、リスク格付レポート、例外レポート、規制または税務報告出力をテストすべきである。レポートは基礎となるローン記録と照合されるべきである。ユーザーは、どのデータフィールドがレポートを駆動し、どの例外がマニュアル判断を必要とするかを理解すべきである。

5つ目の要求はワークフローの証明である。選択されたシナリオについて、購入者はタスク作成、ルーティング、承認、メモ、文書添付、借手通信、例外処理、最終的な記録更新の証拠を要求すべきである。シナリオには、理想的な処理だけでなく、情報の遅延や欠落が含まれるべきである。コベナンツ違反、ローン条件変更、支払変更、建設引出、保険不備が良いテストである。

6つ目の要求は運営上のオーナーシップである。貸手は、どのプロセスを McCracken が設定し、どれを貸手が修正できるか、誰がルール変更を承認するか、ユーザーがどのようにトレーニングされるか、サポートチケットがどのように振り分けられるか、新リリースがどのようにテストされるか、顧客ワーキンググループのフィードバックが製品開発にどのように影響するか、稼働後のヘルスチェックがどのように使用されるかを知るべきである。記録のシステムは、立ち上げ後にガバナンスモデルを持たなければならない。

これらの要求は敵対的なものではない。それらは、購入者が McCracken の公開製品主張を機関固有の証拠に変える方法である。プラットフォームに自信のあるベンダーは、それらに対応できるはずである。それらを省略する購入者は、それでも立ち上げるかもしれないが、受け入れられたローン記録が通常のサービシングの複雑さを生き延びられることを証明していない。

公開情報の不確実性境界

本記事は公開された証拠に依拠している。すなわち、McCracken の公式サイトと製品ページ、公式顧客発表、公開サービスページ、公開ブログ投稿、サードパーティのビジネスプロフィール、OCC、FDIC、連邦準備制度、FFIEC、NIST による銀行およびセキュアソフトウェアガイダンスである。McCracken の顧客テナント、STRATEGY インスタンス、ソースコード、契約、実装計画、サポートポータル、SOC レポート、災害復旧テスト、顧客参照コール、プライベート監査ファイル、ローン記録、借手通信、総勘定元帳統合は一切調査されていない。

公式ページは、McCracken の現在の位置付け、製品モジュール、サービスカテゴリー、企業が表明する規模を説明する上で最も強力である。顧客発表は有用な採用シグナルだが、ベンダーによって選択されたものであり、実装結果を明らかにしない。Banking CIO Outlook の2019年のプロフィールは、市場プロフィールシグナルとインタビューベースのコンテキストとして有用だが、製品パフォーマンスの独立した監査として扱われるべきではない。BBB、LinkedIn、歴史的なニュースソースは、アイデンティティとフットプリントの確認に役立つが、ソフトウェア品質には役立たない。

規制および標準参照は McCracken を保証するものではない。それらは、貸手が運営される管理環境を定義している。すなわち、ローン審査、信用格付、CRE 管理システム、内部監査、サードパーティリスク、テクノロジー開発と保守、アウトソースされたテクノロジーのレジリエンス、セキュアソフトウェア開発である。それらはあらゆる商業ローンサービシングシステムの評価基準としてここで使用されている。

証拠は焦点を絞った結論を裏付けている。McCracken は長期にわたる専門的な商業ローンサービシングおよび資産管理ソフトウェアプロバイダーであり、その STRATEGY プラットフォームは、ローン条件、支払、コベナンツ、担保、ワークフロー、会計、投資家報告、リスク格付、保険、レポートなど、貸手が保持する必要がある運用記録に公的にマッピングされている。証拠は、すべての実装がクリーンであること、すべてのホスト環境が特定の銀行の基準を満たすこと、すべての移行が低リスクであること、すべての顧客がコストとリスクを削減したことを証明するものではない。これらの主張には顧客固有のデューデリジェンスが必要である。

評決

McCracken Financial Software は、STRATEGY が広範なポートフォリオビューを表示できるかどうかで判断されるべきではない。実際のローンアクションの後に、貸手が受け入れられたサービシング記録を信頼できるかどうかで判断されるべきである。公開製品表面は、支払適用、変動金利処理、延滞・繰延利息、エスクロー、準備金、投資家送金、担保証拠、レントロール、検査、保険、建設予算、コベナンツトリガー、リスク格付、プロセスワークフロー、レポート、データ移行、ホスト型運用など、商業用および集合住宅サービシングに固有かつ具体的であるため、信頼性がある。

その特化性が McCracken の強みである。それは同時に実装リスクの源泉でもある。サービシング、会計、担保監視、報告に深く踏み込むシステムは、深く設定され、管理され、テストされなければならない。購入者は、システムが権威あるものになる前に、相応の作業を予期すべきである。また、システムが手動作業を置き換え、経営陣にポートフォリオリスクのよりクリーンなビューを提供するなら、相応の価値を予期すべきである。

最も強力な購入ケースは、商業サービシングが運用管理の問題であることを既に認識している機関向けである。すなわち、銀行、保険会社、住宅ローン銀行、準政府機関、CDFI、プライベートレンダー、そしてスプレッドシート、非接続システム、手動リマインダーがもはや容認できないほど複雑なポートフォリオを持つブリッジレンダーや建設レンダーである。これらの購入者にとって、McCracken は評価セットに含まれるべきである。決定は証拠に基づくべきである。すなわち、照合される移行後の記録、正しいタスクをトリガーするコベナンツ、最新に保たれる担保情報、会計と投資家報告に正しく流れる支払、デューデリジェンスに耐えるサポートとホスティングの管理、スプレッドシートへの逆戻りをやめるユーザーである。

これらのテストを通過すれば、McCracken の価値はダッシュボードの幅ではない。その価値は、商業ローン記録を、貸手が行動でき、監査人がレビューでき、投資家に報告でき、借手にサービス提供でき、ポートフォリオマネージャーが驚きになる前にリスクを認識できるほど永続的なものにすることである。