要約

  • 書類提出を委任された業者には、それだけで顧客アカウントの管理権限や年次確認を行う権限が与えられるわけではない。
  • 外部の担当者を顧客側のアカウント管理者に別途任命することは可能だ。外注する仕事の範囲と付与する権限を合わせる必要がある。
  • SECは一括委任を認める一方、一括の年次確認は拒否した。準備作業の効率化と、提出者ごとの点検を区別する設計である。

提出は外注済み。だからアカウントも大丈夫――この省略が、EDGAR Nextでは通用しない。

米SECの電子提出システムには、書類を送る権限と、送信元となるアカウントを管理する権限がある。代行業者は前者だけを持つことができる。毎年、そのアカウントの人員や委任先が引き続き正当な権限を持ち、登録情報が正しいと確認するのは、顧客アカウントの管理者の仕事だ。

同じ業者に両方を任せる道はある。ただし、契約書に広い言葉を書くだけでは、狭く定義されたシステム上の権限は広がらない。「提出対応一式」の一式を分解すると、別々の仕事と別々の権限が出てくる。

アーカイブは残る。作業チームは組み直しになる

年次確認を放置した場合の仕組みを見ると、この仕事の正体が分かる。SECの確認手順では、期限を過ぎても3か月間は通常のアクセス、提出、アカウント操作が可能だ。その猶予期間を終えても確認しなければ、アカウントが無効化され、Form IDによるアクセス申請が改めて必要になる。

SECが申請を承認すれば、CIK番号と過去の提出履歴は引き継がれる。一方、以前の個人への権限付与や委任は、そのまま再び有効にはならない。新たに指定された管理者が人を招待し、必要な委任を設定し直す。

公開記録が消える話ではない。仕事を動かす人と権限の配置を作り直す話である。アクセスの復旧を、単なるパスワード再設定と同じ作業として見積もると、この部分が抜ける。

どれだけの費用になるかは、各社の管理時間、確認漏れの頻度、契約に含まれる復旧支援によって変わる。その実績がなければ金額は出せない。ただ、追加の申請や再招待を誰かが行うという作業の発生箇所は、制度に明記されている。

業者の管理者と顧客の管理者は別の帽子

SECのFAQによれば、EDGAR Nextの要件は2025年9月15日から適用された。従来のログイン方式は終了し、個人ごとのLogin.gov認証、多要素認証、適切な役割を使う。各書類の提出期限や開示義務は、それぞれの規則に従って続く。

役割の説明では、アカウント管理者は人員や委任、年次確認を管理し、書類も提出できる。他方、別のCIKを持つ業者に提出を委任すると、その業者のアカウント管理者は顧客に対する委任先管理者となる。顧客のために提出し、自社のどのユーザーを担当させるかを選べる。

この委任だけで、顧客の管理画面を開いてアカウントを管理する権限までは得られない。顧客側も、自分の画面から業者の従業員を管理する仕組みではない。二つの組織をつなぐ委任には、きちんと境界が残る。

そのため、業者が昨日の書類を問題なく提出できたとしても、顧客の年次確認を今日行える証明にはならない。確認すべきなのは、会社間の取引関係に加え、誰が顧客アカウントのどの役割を持っているかだ。

業者の担当者を、顧客のアカウント管理者として別途任命することはできる。EDGAR提出者マニュアル第I巻・第43版は、Form IDで会社やその関連会社の従業員ではない人を指定する場合、権限を与える者の公証された署名を含む委任状を求めている。既に権限を持つ管理者が後から管理画面で招待する経路とは異なる。初回申請の書類要件を、以後のすべての招待に当てはめてはいけない。

外注できるか、という問いだけなら答えは出る。より重要なのは、どの管理機能まで任せ、交代時に誰がその権限を引き継ぐかだ。

二人必要でも、二人採用するとは限らない

一般にアカウント管理者は最低二人必要だ。個人と、制度上の「single-member company」には一人でよい例外がある。後者は一人の自然人が唯一の持分保有者であり、取締役と役員、または相当する地位を兼ねる場合を指す。「株主が一社だけ」という意味まで広げられる例外ではない。

管理者の人数を、そのまま新規採用の人数に換算するのも早計だ。一人が複数の提出者について役割を持つことは可能で、外部の人の任命も認められている。必要なのは適切に権限を与えられ、実際に動ける人だ。

技術的な接続にも別の役割がある。APIを直接利用する場合は技術管理者の要件があるが、二人の技術管理者という要件を満たす委任先のAPI接続を使えば、顧客自身の技術管理者や提出者トークンを用意せずに利用できる。ここでは運用をまとめる利点がある。

それでも、その接続を提供することと、顧客アカウントの年次確認をすることは別だ。技術を共有して削減できる仕事と、顧客ごとに残る管理責任を、見積もりの段階から分ける必要がある。

一括処理を認めた場所、止めた場所

SECが最終規則で明確に拒否したのは、関連する複数のアカウントを年次確認でまとめて承認する提案だった。管理者やユーザー、連絡先が似ていても、提出者ごとの情報は異なり得る。数百のアカウントを一度に確認する操作が、個別の慎重な点検に取って代わることを懸念した。

一方で、大量の委任や複数の招待の一括受諾、APIによる準備作業は認めた。大量の書類を扱う業者に、小さな会社の手作業をそのまま何百回も繰り返させる設計ではない。情報の収集と整理は効率化し、最後に「この提出者の情報を確認した」という単位を残す設計だ。

年次確認では、登録された人や委任先の権限が引き続き有効か、情報が正しいかを調べ、誤りを直してから確定する。アカウント管理者のうち一人が実施できる。一般に管理者が二人必要なことと、二人の共同署名が必要なことは同じではない。

期限は3月31日、6月30日、9月30日、12月31日から選ぶ年一回の予定で、EDGARの休業日なら次の営業日となる。通知は6週間前から始まる。前の四半期に繰り上げて確認すると、次の期限も変わる。SECの例では、12月31日期限を8月に確認した場合、翌年9月30日が次の期限になる。完了だけを記録して翌年の予定を据え置けば、早めに済ませた仕事が別の取りこぼしを生む。

委任手順は、既存の提出契約を前提とし、似た名前に惑わされず正確なCIKを確かめるよう求める。委任は相手の同意を得ずに解除できる。その出口を使うには、顧客側に操作できる権限保有者が必要だ。契約解除の自由は、管理画面で実行できて初めて実務になる。