--- title: "Insider Trading Preclearance Workflow | Kylon" description: "How a compliance desk reviews personal trade preclearance requests against insider tiers, blackout windows and the restricted list, with a person issuing every clearance." url: "https://kylon.io/use-cases/insider-trading-preclearance" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Insider Trading Preclearance: Clearances That Respect Tier, Blackout and Restricted List Use Case7 min read # Insider Trading Preclearance: Clearances That Respect Tier, Blackout and Restricted List Personal trade preclearance requests are reviewed in one Kylon room. Agents check each requester's insider tier in Outlook, blackout windows on Google Calendar and the restricted list, and a compliance officer issues every clearance. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## 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 People - Compliance officer Issues every clearance, denial and referral, and signs the closeout per tier - Compliance analysts Keep the clearance log, confirm unclear tiers and answer requesters - Counsel's office Sets blackout windows, maintains the restricted list and reads unclear cases Agents - AdaPreclearance reviewer Checks each request against the requester's tier, blackout windows, the restricted list and any trading plan, and proposes a verdict and a monitoring tier [Notion](https://kylon.io/integrations/notion)OutlookGoogle CalendarGoogle Drive - RyanLog auditor Audits the clearance log line by line, applying review codes in the policy's order of precedence, and builds the closeout per tier [Notion](https://kylon.io/integrations/notion)Google Drive[Slack](https://kylon.io/integrations/slack) 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. ```mermaid flowchart TD open([An automation opens the week's
review with the open requests]) unclear["Compliance analysts confirm
any tier that is unclear"] tier["Ada reads each requester's tier
from the designation notices"] verdict["Ada proposes a verdict with
the code that applies first"] issue["Compliance officer
issues every verdict"] watch["Ada proposes each monitoring tier,
HIGH_WATCH near the tier limit"] audit["Ryan checks the log for code
precedence and missing entries"] okwatch["Compliance officer approves
the monitoring tiers"] fixlog["Compliance analysts
correct the log"] change([A blackout, restricted list
or trading plan changes]) rerun["Ada reviews every open request
again, changed or not"] reaudit["Ryan checks the new log
entries for precedence"] okchange["Compliance officer approves
each changed verdict"] closeout["Ryan builds the closeout per tier
from the final verdicts"] sign["Compliance officer signs the closeout"] open --> tier --> verdict --> issue --> watch & audit unclear -.- tier watch --> okwatch audit --> fixlog okwatch & fixlog --> rerun change --> rerun rerun --> reaudit --> okchange --> closeout --> sign class tier,verdict,watch,audit,rerun,reaudit,closeout agent class unclear,issue,okwatch,fixlog,okchange,sign person class open,change event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Tier check | The requester's tier is read from the designation notices in Outlook, not from the request form | Ada | Compliance analysts confirm any tier that is unclear | | Verdicts | Each request is cleared, denied or referred, with the code that applies first in the policy's order | Ada | The compliance officer issues every verdict | | Monitoring tiers | Cleared trades at nine tenths of the tier limit or above get HIGH\_WATCH, and anything not cleared gets NONE | Ada | The compliance officer approves | | Log audit | The clearance log is checked line by line for code precedence and missing entries | Ryan | Analysts correct the log | | Blackout, list or plan change | Every open request is reviewed again under the new window, list or adopted plan | Ada, then Ryan | The compliance officer approves each changed verdict | | Closeout | Totals per tier from the final verdicts in Notion | Ryan | The compliance officer signs the closeout | Stages of a weekly preclearance cycle. Request numbers, tiers and limits in this example are illustrative. ## 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](https://kylon.io/integrations/notion) - Outlook - [Slack](https://kylon.io/integrations/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. Set-up prompt Set up our insider trading preclearance desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Google Calendar, Google Drive, Notion, Outlook and Slack. Tell me which ones still need connecting, including the lasting grant to read the compliance mailbox in Outlook. 2. Ask me who works this desk: the compliance officer who issues every verdict and signs the closeout, the compliance analysts who keep the log and confirm tiers, and the counsel's office who sets blackout windows and maintains the restricted list. Help me invite them to this Room. 3. Build a Preclearance App with Request, Tier, Verdict and Status columns, one record per open request. Pull the open requests from the Notion database. 4. Check each request against the tier designation notice in Outlook, the blackout windows in Google Calendar, the restricted list and policy in Google Drive, and any trading plan on file. Propose a verdict, a review code in policy order and a monitoring tier for each, and show me the ones that need a closer look. 5. Draft each clearance notice in Outlook and hold every draft until the compliance officer approves and sends it. Make no log writes until analysts have corrected any flagged entries and the compliance officer approves each changed verdict. 6. Write our rules, our checks and who approves which verdict, notice and closeout into this Room's guideline so every request follows it. 7. After one clean week, offer to turn the recurring review into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### Annual Credit Review: Limits and Holds Set by Policy, Account by Account Twenty-six credit accounts, one limit table and a steady stream of corrections. Agents in one Kylon room read Stripe payment history and Box credit reports and propose each limit and hold for Salesforce, and the credit lead approves every change before it is written. Financial servicesFinance operationsApprovals & reviews ](https://kylon.io/use-cases/customer-credit-review)[ ### Gifts and Entertainment Review: A Quarterly Register That Adds Up by Counterparty The quarterly gifts and entertainment review runs in one Kylon room. Agents check each Notion declaration against Outlook pre-approvals, tender windows on Google Calendar and running totals per counterparty, and a compliance officer sets every final status. Financial servicesCompliance & risk ](https://kylon.io/use-cases/gifts-and-entertainment-review)