eFAST eSECURE 難解なSECのオンラインシステム

この記事では、フィリピンSECのオンラインシステム――とくに eSECURE・eFAST・eAMEND の構造的な違和感を、自分の備忘録として整理します。

1. 表向きの「親子関係」と現実のギャップ

SECは「eSECUREを親ポータル」として、その下に eFAST や eAMEND などの各種オンラインサービスをぶら下げる構想をうたっています。
しかし実際に触ってみると、見かけ上は親子関係なのに、中身はほぼ別システムというねじれが随所に現れます。
このため、目的とするサイトに入るために、何のアカウントが必要なのか、しばしば分からなくなります。典型例が eSECURE と eFAST の関係です。
eSECUREで個人アカウントにログインし、そこから eFAST へのリンクを踏むと、一見「ポータルから子システムに入った」ように見えます。ところが eFAST 側では改めてログイン画面が出てきて、独自のユーザー(法人もしくはfiler個人)でログインしなおさなければなりません。
eFASTからログアウトしても、eSECURE側のログイン状態はそのまま残る。つまりセッションが共有されておらず、ただリンクでつながっているだけです。

結果として、UIはポータル構造なのに、認証・権限管理はバラバラという、ユーザーから見て非常に混乱しやすい構造になっています。

2. eSECUREアカウントとは何者か

eSECUREで作成するのは「個人アカウント」であり、メールアドレスや携帯番号、本人確認用のID、自撮り写真などをアップロードし、フィーの支払いまで完了した「認証済みの個人ID」です。
法人アカウントという概念はなく、「この人はSECが本人確認した個人である」というデジタル身分証のような位置づけです。

この eSECURE アカウントは、新法人の発起人(incorporator)や authorized representative が、オンラインで会社設立や重要な登記変更を行うときに使われます。
逆に言うと、オンラインで設立行為に関わった人は、少なくとも一度は eSECURE アカウントを作り、credential(本人確認+支払いPHP400)まで完了させているはずです。
ポイントは、eSECUREの世界は「個人」と「本人性」にフォーカスしており、法人との紐づけはあくまで後付けであるということです。

3. eFAST:法人ベースの「報告システム」

これに対して eFAST は、AFS や GIS などを提出するためのシステムで、「Filer個人ベース」と「法人ベース」の2つがあります。どちらでログインしたかは、ログインするまでわかりません。メニューが微妙に異なっています。
「Filer個人ベース」でログインすると、担当する法人を選択できる形になっており、会計事務所の担当者が使用することが想定されています。担当する法人を個人アカウントの側から追加することはできません
「法人ベース」でログインすると、ペンディング中の申請を見ることができます。ただし、過去のGISを閲覧できるというわけではありません。
これらのアカウントは、eSECUREアカウントとは完全に別で、eSECURE アカウントがなくても利用できます。そのため、eSECUREでログインしていても、eFASTでは別ユーザーでログインできてしまいます。

4.GISを出すためにFilerになりたい。さてどうすれば

①eFASTの法人アカウントに入ります。eFASTの法人アカウントに入れない場合は詰みます。通常、SEC登録時に、自動的にアカウントが作られ、そのメールがSECから勝手に送られてくるため、殆どの人は見落とします。

Authorized Filer > Add Authorized FilerボタンからFilerを追加する。
NotrizeされたSecretary Certificateをアップロードする必要あり。
③おそらくSEC担当者が手動で書類を確認し、紐づけを行っていると思われます。
④eFAST個人アカウントからログインすると、法人として先程の法人が追加されているのでGISを提出可能な状態になる。

5. eAMEND:eSECURE前提だが法人とは「後から紐づけ」

eAMENDは、社名変更や事業目的変更などをオンラインで申請するためのシステムだが、eAMEND に入るには、credential 済みのeSECUREアカウントが必須であり、eFASTのfilerアカウントではログインできない。

しかしログイン後の画面構造を見ると、eAMEND自体は最初から特定法人と紐づいているわけではない。
ユーザーが自分で SEC Registration Number(会社の登録番号)を入力し、その番号から対象法人を検索・選択する形になっている。

ここで気になるのが次の点だ。

自分が発起人として関わった法人だけが選べるようになっているのか

それとも、SEC登録番号さえ知っていれば、任意の法人を選んで申請を進められてしまうのか

マニュアル類を見る限り、システム上は後者に近い挙動で、発起人かどうかで機械的に制限するような記述はない。
権限チェックは、「Board Resolution / Secretary’s Certificate で authorized representative として指名されているか」「添付書類・電子署名が正しいか」といった、書類と審査で担保する前提になっている。
つまり、eAMENDは「KYC済みの個人ID(eSECURE)」と「法人登録番号」をその場で組み合わせて申請を作る仕組みであり、発起人情報で自動制御しているわけではないと理解した方が現実に近い。

5. 三つ巴構造の気持ち悪さ

ここまでの構造をまとめると、次のような三つ巴になる。

①eSECURE
個人ベースのKYC・credential。
新設・重要な登記変更・電子署名の「身元の証明」。

②eFAST
法人ベースの年次報告システム。
company account と filer という独自ユーザー体系。
eSECUREとは無関係。

③eAMEND
社名変更・事業目的変更など「定款レベルの変更」用。
ログインするにはeSECUREアカウントが必要。
法人との紐づけは SEC登録番号ベース。
eFASTとは無関係。

UI上は「eSECUREポータル → いろいろなサービス(eFAST / eAMEND / eSPARC…)」という綺麗な階層構造に見える。
しかし実際の認証と権限管理は、シングルサインオンとも、きれいな親子関係とも言いがたい状態になっている。