どのようにしてアメリカの金融検証プラットフォームがIron Suiteにドキュメントスタックを統合したか

要約

• 業界: ファイナンシャルサービス — 米国拠点の収入および雇用確認プラットフォーム、マルチテナントおよび顧客管理データセンター内でホスティングされています。
• Iron製品: IronPDF, IronOCR, IronBarcode, IronXL, および IronSecureDoc — 完全な Iron Suite。
• ワークフロー: PDF生成、PII削除、バーコードベースの追跡、Excelエクスポート、および検証注文全体のデジタル署名。
• 主な成果: 単一のベンダードキュメントスタック、強化された削除および署名体制、予測可能な5年間のライセンス基盤。
• ライセンスモデル: Iron Suite Enterprise OEM、永続的な基本ライセンス、5年間のサポートおよび製品更新。

課題

iTextからの移行は、並行して解決すべきビジネス、技術、商業の3つの明確な問題によって推進されました。

ビジネスプレッシャー: iTextの総コストが上昇していました。 開発、テスト、プロダクションサーバーにわたるマルチテナント検証プラットフォームの運用は、成長を続けるフットプリントのiText権利を支払うことを意味していましたが、成熟した商業用PDFライブラリの更新計算は良い取引のようには感じられませんでした。 コストに加えて、コンプライアンス負荷がかかります: 収入、雇用、および税ドキュメントを扱うプラットフォームは大量のPIIを処理しており、毎年削除および署名を単に技術的に正確ではなく、監査可能にするプレッシャーが増しています。 プラットフォームは、そのフットプリントにペナルティ型の更新なしでスケール可能なベンダーが必要であり、ドキュメント生成だけでなくコンプライアンスの表面をカバーする機能セットを備えている必要がありました。

技術的な壁: ドキュメントミックスが最も難しい部分でした。 検証ドキュメントはクリアなデジタルPDF、スキャンされたアップロード、およびファックス品質の画像として届きます — 時には単一の注文内で3つすべてが含まれます。 そのミックス全体で社会保障番号を確実に検出するには、単に生のテキスト出力ではなく、座標認識テキスト抽出を備えたOCRが必要でした。なぜなら、削除が正しい境界ボックスに収まる必要があるからです。 内部トラッキングは別のレイヤーを加えます: プラットフォームは、カスタムフォントを使用して既存のPDFフォームフィールドにバーコードを埋め込みます。フォームフィールドフォントパスには、置き換えライブラリが対応すべき特定の動作があります。 すべて.NET Framework 4.6.2+上で動作しなければならず、静かにレガシーフレームワークサポートを廃止した新しいライブラリは除外されました。

商業的な障害: 2つの商業的質問が購入前に解決される必要がありました。 第一に: ホストされた検証プラットフォームの運用はOEM使用としてカウントされるのか、または外部再頒布としてカウントされるのか? プラットフォームのテナントがプラットフォームが生成したドキュメントを消費します — 彼らはIron APIを直接呼び出すことはありませんが、ライセンスの定義は法務および調達にとって重要でした。 第二に: ライセンスサーバーは停止時にどのように振る舞うのか? ライセンスチェックがタイムアウトしたために検証プラットフォームが注文処理を停止することはできません。 両方の質問はマーケティングの安心ではなく、書面による回答が必要でした。 それ以外のすべては — コストの予測可能性、複数年の価格設定、割引構造 — これらの2つから派生しました。

Iron Softwareが支援した点

現在、プラットフォームのドキュメントパイプラインは、統一されたIron Suiteスタックを通って動作しています: IronPDFがHTMLからPDFへのレンダリング、フォームフィールド、および署名を処理します; IronOCRが削除のための座標認識テキスト抽出を駆動します; IronBarcodeがトラッキングコードを生成および読み込んでいます; IronXLがクライアントおよび内部運用のためのExcelおよびCSVレポートを作成します; そして、IronSecureDocが署名、保護、および不可逆的な削除のためのローカルRESTサービスとして動作しています。 iTextは退役の道にあり、5年間のEnterprise OEM契約が商業基盤として設置されています。