Insider Trading Preclearance: Clearances That Respect Tier, Blackout and Restricted List

Preclearance is quick until the calendar and the list change in the same week

A preclearance request is a short question with a strict answer. Is the requester in a tier that needs clearance? Is a blackout open? Is the security on the restricted list? Does the trade fall under a pre-arranged trading plan, and is its size within the tier's limit? The policy sets the order in which those reasons apply, and the first one that applies decides the review code.

Requests are filed in a Notion database. Tier designations are notices in the compliance mailbox in Outlook, blackout windows are on a shared Google Calendar, and the restricted list and the policy sit in Google Drive. When counsel extends a blackout or publishes a new restricted list, every open request needs a fresh look, and the clearance log has to carry the right code for each one.

Who works in the room

Preclearance runs in one room with strict guidelines. Ada is the default agent and reviews every request, and Ryan owns the audit of the clearance log. A question about a single request goes to Ada; a question about how an entry was coded goes to Ryan. When Ada re-reviews the population after a change, it hands the new verdicts to Ryan in the thread, and Ryan checks the codes before the compliance officer sees the list. One agent leads the thread at a time, so it is always clear whose verdicts are current.

A week of requests, verdict by verdict

An automation opens the week's review every Monday with the open requests from Notion. Every pass ends with a verdict for every open request, including the ones that did not change, so the log is complete each time.

When counsel moves the blackout

Counsel extends the quarterly blackout by a week because results are delayed, updates the calendar and posts the change in Slack. Ada does not look only at requests dated inside the extra week. It re-runs every open request against the new window, the current restricted list and any trading plans adopted since the last pass, and produces a verdict for each one, changed or not.

Restricted list v2 works the same way. A security added to the list denies any open request in it, whatever the tier, and a security removed may turn a denial into a clearance, subject to every other check. Ryan audits the new log entries for precedence, the run history shows which list version each verdict used, and the compliance officer approves the changes before Ada drafts any clearance notice in Outlook.

What the checks catch

• A requester whose tier on the request form does not match the designation notice in Outlook
• A log entry coded for size when a blackout applied first and should decide the code
• A cleared trade near the tier limit that belongs on HIGH_WATCH, or a denied request with any monitoring tier other than NONE
• A re-review that reports only the changed requests and leaves the log without a verdict for the rest
• A trading plan adopted midweek that changes how a pending request is treated

What stays with people

• Issuing every clearance, denial and referral
• Sending each notice to a requester, which Ada drafts in Outlook for a compliance officer to send
• Reading a request where the policy or a trading plan leaves room for doubt, together with counsel
• Signing the closeout for each tier

Integrations in this workflow

Kylon is not a personal trading surveillance system and it does not replace one. It sits between the request database, the mailbox and the calendar the desk already keeps, and holds the review in one place.

• Google Calendar
• Google Drive
• Notion
• Outlook
• Slack

• Notion holds the request database, the clearance log and the closeout pages
• Outlook holds the tier designation notices and carries clearance notices as drafts a person sends
• Google Calendar carries the blackout windows that counsel maintains
• Google Drive keeps the policy and every version of the restricted list
• Slack is where counsel announces blackout and list changes to the desk

Where to start

Begin with one week of requests. Connect the Notion database, give Ada a lasting grant to read the designation notices in the compliance mailbox, approved by the mailbox owner, and write the one rule into the room guidelines: agents propose verdicts and codes, and only a compliance officer issues a clearance.

“Every re-review gives every request a verdict, so the log is complete each time, not just where something changed.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.