Building a JSON Conduct Policy

The following sections details step-by-step instructions on how to create a Conduct policy based on the following use cases:

Use Case 1 - Standard Policy - Insider Information

A Standard policy uses both WORDSANDPHRASES and FILTERS.

Create a Standard policy for Insider Information to identify insider trading within an organization. That is, the policy must identify the employee communication sharing information about stocks and share prices through a communication tool or collaboration network.

Step-by-Step Instructions

  1. Identify the list of terms that are usually used in insider trading. Add them inside the WORDSANDPHRASES field or in the LEXICONS field. You can also use a combination of both.
    In the example, Fundraising, Shares, Stock, Transactions are the terms identified.

  2. Identify the MUSTX occurrence criteria to be followed.
    In the example, MUSTANY is the occurrence used.

  3. Identify the zones in the communication to be monitored. Create a ZONES section and add the identified zones.
    In the example, Subject and Body are the zones used.

  4. Identify the valid attributes to be specified in the ROLES field.
    In the example, to/cc/bcc along with endpointids attribute is used.

  5. Identify the employee/participants or groups whose communication needs to be monitored. Create PARTICIPANTS section.
    In the example, ALL participants with the specified ROLES are used.

  6. Identify the tool or collaboration network to be monitored and add them in the NETWORKS filter.
    In the example, lync, aim and Sharepoint are used.

  7. Identify the channels to be monitored and add them in the CHANNELS filter.
    In the example, journal, chat, email, im are used.

Sample Insider Information Policy - Standard Policy
{
"WORDSANDPHRASES" : {
"MUSTANY" : {
"ZONES" : ["Subject","Body"],
"TERMS" : ["fundraising","Hot* FOLLOWEDBY Stock~","share*"],
"LEXICONS" : ["LexSet1","LexSet2","LexSet3"]
}
},
"LEXICONS" : {
"LexSet1" : ["Unethical",
"What FOLLOWEDBY,6 happened to my mutual fund",
"What FOLLOWEDBY,6 happened to my polic*"]
"LexSet2" : [""guarantee", "stock", "profit"]
 
"LexSet3" : ["additional | add'l FOLLOWEDBY,1 info* for the above FOLLOWEDBY,2 trade* | transaction*
(buy | bought | b FOLLOWEDBY,2 shares | units)"
},
"FILTERS": {
"PARTICIPANTS": {
"MUSTALL": {
"AND" : [
{
"ROLE": "to/cc/bcc",
"ENDPOINTIDS" : ["@ao*l.com"]
},
{ "OR" : [
{"ROLE": "to/cc/bcc",
"GROUPS": [ "GWM"]
},
{"ROLE": "to/cc/bcc",
"GROUPS": [ "Advisor"]
}
]
}
]
}
},
"NETWORKS":[
"lync",
"aim",
"sharepoint"],
"CHANNELS":[
"journal",
"chat",
"email",
"im"]
}
}

Use Case 2 - Lexicon-only Policy - Bribes and Kickbacks

A Lexicon-only policy has TERMS defined either as a LEXICON or LEXICON_LIST without FILTERS.

Create a Lexicon-only Policy for Bribes and Kickbacks in an organization. That is, the policy must identify the employee communication on bribe and kickback incidents.

Step-by-Step Instructions

  1. Identify the list of terms that are usually used in a bribe or kickback communication. Add them to the Lexicon file.
    In the example, terms identified are listed in BribeKickback1 and BribeKickback2 files.

  2. Upload the Lexicon file to Enterprise Archive.

  3. Identify the MUSTX occurrence criteria to be followed.
    In the example, MUSTANY is the occurrence used.

  4. Specify the file names in the LEXICON_LIST field.

Sample Bribe and Kickback - Lexicon-only Policy
{
"WORDSANDPHRASES": {
"MUSTANY": {
"LEXICONS_LIST": [
"BribeKickback1",
"BribeKickback2"
]
},
}
}
Sample Lexicon File
pay off* | pay-off* | paid off PRECEDEDBY,2 accept* | receiv* | take* | taking | took
pay* | paid FOLLOWEDBY,1 her | him | me | them | their | there | they*re | you* | us FOLLOWEDBY,2 off
pay* up PRECEDEDBY,3 time to | you | u
pocket PRECEDEDBY back | in my | in our | in his | in her | in their | in there | in they*re
pretend* FOLLOWEDBY,2 don* | did not | didn*t | had no | have* | never FOLLOWEDBY,1 hear* | know* | knew
priceless FOLLOWEDBY,3 info*
promis* FOLLOWEDBY,2 will not | will never | won*t | would not | wd not | would*nt | wdn*t
promis* FOLLOWEDBY,2 secret | secrecy | silence | silent 
Sample Lexicon File
risky PRECEDEDBY to | too
ruin FOLLOWEDBY,1 her | him | his | them | their | there | they* | ur | you*r*
schtup* | shtup*
scratch* your back | scratch* UR back | scratch* my back
secret PRECEDEDBY,2 our | little
share FOLLOWEDBY,2 profit
worth FOLLOWEDBY,2, her | his | my | our | you*r*

Use Case 3 - Filter Only Policy

A Filter-only policy has only FILTER filed without any references to LEXICON or LEXICON_LIST.

Create a Filter-only policy to fetch all communication with either attachments sent or received between specific dates from certain networks.

Step-by Step Instructions

  1. Identify the type of attachments within communications to be filtered.
    In this example, PDF and doc are the file types. Add them under FILE_EXTENSIONS filter.

  2. Identify the communication types.
    In this example, external mixed outbound is the communication type. Add them under COMMUNICATION_TYPES filter.

  3. Identify the networks from where the communications must be filtered.
    In this example, lync network is the network. Add lync under NETWORKS filter.

  4. Identify the date range to filter the content.
    In this example, communications archived between 12 October 2018 and 14 October 2019 are filtered. Create a DATE filter accordingly with respective attributes.

Filter-only Policy
{
"FILTERS": {
"AND": [
{
"FILE_EXTENSIONS": [
"pdf",
"doc"
]
},
{
"OR": [
{
"COMMUNICATION_TYPES": [
"external mixed outbound"
],
"NETWORKS": [
"lync"
]
},
{
"DATE": [
{
"DATE_TYPE": "Archived",
"RANGE_TYPE": "Between",
"FROM": "2018-10-12T12:10:30",
"TO": "2019-10-14T11:20:30"
}
]
}
]
}
]
}
}