各行が手間をかけて要件をまとめる努力をするのは、個別機能をできるだけ減らすためだ。個別機能が増えては、維持コストの削減といった共同化のメリットが損なわれてしまう。
「第3次オンラインの過ちは繰り返さない」。常陽銀の鶴田システム部長は意気込む。同行が利用する「Chance」は三菱東京UFJ銀行のシステムをベースに構築したもの。百十四銀行や十六銀行など6行が共同で利用する。このChanceの結成前も、常陽銀、百十四銀、十六銀は旧三菱銀のシステムをパッケージとして利用していた。ある意味、共同化していた。しかし、各行が個別開発の機能を増やした結果、似て非なるシステムになってしまった。そこでChanceでは、個別機能の肥大化を防ぐとともに共通機能には各行が勝手に手を入れることができない仕組みを作り上げた。
まず、勘定系アプリケーションのモジュールを「三菱東京UFJ銀のパッケージ（P）」「地銀共通（K）」「各行独自（O）」の3層に分類。その上で「K」と「O」の合計を全体の5％以内に抑えるという数値目標を定めた（図6）。内訳は「K」が3％で「O」が2％である。
昨年1月から1年半の間に4地銀が利用開始する移行ラッシュを過ぎた直後なので、現在は一時的に「O」が5％前後に達しているという。各行が安定稼働フェーズに移るのと、この年末に三菱東京UFJ銀がシステム完全統合「Day2」を完了させるのを待ってから、5％ルールに沿うように、OをKに格上げしたり、KをPに格上げしたりする。共通機能を完全な同一仕様に維持するためには、「P」と「K」「O」のライブラリを厳密に分けて管理する。
同様に、アプリケーションを階層分けした上で共通部分は勝手に修整できない「聖域」と位置付けている陣営は多い。Windowsで動作する日本ユニシス製システム「BankVision」を利用する陣営も、第1号ユーザーである百五銀行をベースとしたパッケージの機能に後続行が合わせる。百五銀は「複数行での利用を前提に、共通機能と個別機能を明確に分けて設計した」（萬濃輝典システム統括部副部長）。
