The 2GCG group in an AL3 file stands for Group Control Group, and its purpose is to inform the receiving system about data element groups that are intentionally not included in the current transaction, either because:

• They are not applicable in this context, or
• They are typically included in a master file but were intentionally omitted here, without implying deletion.

Primary Uses of the 2GCG Group:

1. Prevent Unintended Deletion:

• When a data group is missing from a transaction, the receiving system might assume it should be deleted.
• The 2GCG group prevents that by explicitly stating: “This group is not present, but don’t delete it.”

2. Clarifies Data Omission Intentions:

• Some groups may never be sent at all in policy images (e.g., because they are irrelevant to the policy type).
• Others may be omitted just in this transaction but still exist in the master policy record.

3. Supports Package Policies:

• In package policies (e.g., CPKGE or BOP), multiple 2GCG groups can follow the 2TCG (Transaction Control Group).
• For groups omitted across the entire package policy, use 2GCG with LOB code PPKGE (Personal Package) or CPKGE (Commercial Package).
• For groups omitted only in a specific leg (e.g., Auto, Property), use 2GCG with the specific LOB code (like AUTOB, PROP, DFIRE, etc.).

4. Maintains Data Integrity:

• By providing a list of omitted-but-not-deleted groups, the receiving system can accurately merge or maintain its existing data without errors.

Practical Example:

If you are sending an AUTOP policy update that doesn’t include a specific location group (5LAG) — and you don’t want the receiver to assume that location was removed — you’d list 5LAG in the 2GCG group. This tells the receiving system:

“I’m not sending this group right now, but don’t delete it from your records.”

Sample of 2GCG in an AL3 File: