GST Validation And Supplier Blocking Flows

This document maps the GST validation, GST ownership, GST-invalid, and GST-fraud flows seen across supplier-ums, supplier-store, supply-orchestrator, and supplier panel surfaces.

The charts are intentionally vertical and narrow. The descriptions call out which flows directly change supplier validity and which only update KYC metadata, ownership state, or UI visibility.

Quick State Model

Key supplier-store fields and tables to inspect when a seller appears blocked under GST-invalid/Fraud:

Area	Field / Table	Meaning
Account validity	`supplier.valid`, `supplier_legacy.valid`	Whether supplier is active.
Deactivation type	`validChangeType`	`1` active, `2` temporary delete, `3` permanent delete, `4` under review.
QC status	`qcStatusId`	`13` means `Fraud supplier deactivation`; this can exist even when `valid=1` if updated incorrectly.
GST KYC	`supplier_kyc.gstin_status`	Final GST status. Approved requires active GST plus OTP verified.
GST active status	`supplier_kyc.gstin_active_status`	Active/inactive/rejected outcome from GST/EID validation.
OTP ownership	`supplier_kyc.gstin_otp_verification_status`	Whether GST registered contact ownership is verified.
Registered contact	`gstin_registered_mobile`, `gstin_registered_email`	GST/EID registered contacts used for OTP/contact matching.
GST-invalid banner	supplier attribute `gst_invalid_banner`	Enables GST-invalid self-serve reactivation banner.
Reactivation freeze	supplier attribute `last_reactivation_attempt_at`	Used to enforce reactivation cooldown.
GST fraud	`gst_fraud_supplier`	Tracks fraud GST, delinked state, delinked time, verification time.
GST ownership	`kyc_doc_claimed_status`	Maps GSTIN/PAN SHA to supplier and ownership state.
Transition mapping	`supplier_gst_transition`	Old supplier to new supplier mapping for NGST-to-GST transition.
Transition enablement	supplier attribute `enable_gst_transition`	Controls whether NGST-to-GST transition UI/pill is shown.
Registration fraud score	`user_fraud_status_scores`	Stores green/yellow/red fraud result during registration.
Fraud model input	`fraud_suppliers_data`	UMS-side lookup table populated from fraud model output and supplier-store data.
Audit trail	`status_change_logs`, KYC logs	Shows who changed valid/QC/KYC state.

Flow 1: Registration GSTIN Save

[Diagram]

Entry point:

supplier-ums: POST /api/supplier-ums/v1/user/gst/save
Controller: GstVerificationController.saveGSTIN
Service: GstVerificationServiceImpl

Detailed behavior:

The GSTIN is normalized and rate-limited per user.
supplier-UMS asks supplier-store whether the GSTIN is already linked.
GST verification calls the primary provider chain. Code and docs mention Masters India as primary and SurePass/AppyFlow as fallback depending on rollout history.
GSTIN must be active. Inactive status is rejected at this stage.
Taxpayer type maps to platform GST type:
- Regular/Casual: GSTIN
- Composition: COMPOSITE_GSTIN
PAN is extracted from GSTIN characters 3 to 12.
supplier_gst is created/updated with GSTIN, PAN, GST type, and verification response.
If GSTIN is edited mid-registration, existing bank and pickup address details are deleted because those validations are tied to the previous GST identity.
Journey is reset/advanced to GSTIN_ADDED.

Blocking impact:

This blocks registration, not an already-created supplier.
Failure reasons here include invalid GSTIN, inactive GSTIN, duplicate GSTIN, invalid taxpayer type, provider failure, and rate limit.

Flow 2: Registration Enrolment / Non-GST Save

[Diagram]

Entry points:

supplier-ums: POST /api/supplier-ums/v1/user/enrolment/save
EID router APIs: session, captcha, pincode, address, text fields, OTP, generate EID
Controller: GstVerificationController.saveEnrolment

Detailed behavior:

This path is for GstTypeEnum.ENROLMENT, used for non-GST/provisional sellers.
If the user already has an EID, it is saved directly.
If not, EID automation routes the user through the government portal via the EID router/worker flow.
EY ASP verifies enrolment details.
supplier_gst stores the enrolment ID as the GST identifier with gst_type=ENROLMENT.
The EID generation path and EY ASP verification path are separate:
- EID automation generates an enrolment ID.
- EY ASP verifies an already issued enrolment ID.

Blocking impact:

This blocks registration if EID generation/verification fails.
It does not create GST-invalid deactivation because non-GST suppliers are skipped by GSTIN batch validation.

Flow 3: KYC Validation During Registration

[Diagram]

Entry point:

supplier-ums: POST /api/supplier-ums/v1/validate-kyc
Controller: ValidateKycDetailsController
Service: ValidateKycDetailsServiceImpl

Detailed behavior:

Non-IN suppliers are auto-approved for this KYC path.
For IN suppliers, validation combines four checks:
- Bank account verification through payment integration.
- GSTIN/EID verification response.
- Bank account holder name vs GST/EID legal/trade name.
- Pickup address pincode/state vs GST/EID principal address.
Bank name matching uses Levenshtein logic with exception names like NA, UNREGISTERED, and placeholder values.
Strong matches approve bank KYC.
Exception/borderline cases can route to PENDING and require cancelled cheque/passbook upload.
Final GST status is computed through GstinStatusFinder.

Final GST rule:

APPROVED only when:
  gstin_active_status == approved
  and gstin_otp_verification_status == true

If GST is active but OTP is false:
  gstin_status = pending

Blocking impact:

If KYC does not approve both bank and GST, supplier creation may create an invalid supplier or block final registration depending on caller path.
This is not the same as post-registration GST-invalid deactivation.

Flow 4: GST Registered Contact And OTP During Registration

[Diagram]

Entry points:

Contact fetch: SurePass for GSTIN, EY ASP for enrolment.
GSTIN OTP:
- POST /api/supplier-ums/v1/supplier/gst/otp/request
- POST /api/supplier-ums/v1/supplier/gst/otp/resend
- POST /api/supplier-ums/v1/supplier/gst/otp/verify
Enrolment OTP:
- POST /api/supplier-ums/v1/supplier/enrolment/otp/request
- POST /api/supplier-ums/v1/supplier/enrolment/otp/resend
- POST /api/supplier-ums/v1/supplier/enrolment/otp/verify

Detailed behavior:

GSTIN path fetches GST registered mobile/email.
ENROLMENT path verifies supplier mobile/email through EY ASP match responses.
If supplier phone matches registered phone, OTP status can become true automatically.
If phone mismatches and the fraud/experiment gate requires ownership proof, supplier must complete OTP.
On successful OTP verification, supplier-UMS updates supplier-store KYC:
- gstin_otp_verification_status=true
- gstin_status recomputed through GstinStatusFinder

Blocking impact:

If OTP remains false while active status is approved, final GST status remains pending.
This can block approval or later trigger ownership/fraud flows when supplier-store sees OTP status toggles.

Flow 5: Supplier Creation Finalization

[Diagram]

Entry point:

supplier-ums: POST /api/supplier-ums/v1/user/supplier-details/save
Controller: SupplierDetailsController.saveSupplierDetails
Downstream create: supplier-store V4 create through supplier-orchestrator.

Detailed behavior:

Requires saved GST/EID and bank details.
Checks that user is not already in terminal SUPPLIER_CREATED.
Validates email/user/supplier uniqueness.
Rechecks registered contacts during create request construction.
Builds supplier-store create payload with:
- GST type, GSTIN/EID, PAN
- GST active status
- final GST status
- OTP verification status
- registered mobile/email
- bank status and response
- pickup address
- fraud score attributes
supplier-store persists supplier legacy/entity/KYC records and emits async operations.
supplier-UMS writes supplier details, role mapping, journey state, terms, and async post-submit fanout.

Blocking impact:

If KYC status is not fully approved, supplier may be created invalid depending on request/result.
Fraud score can publish a platform-level fraud event when status is red.

Flow 6: Supplier-Store Create/Update GST Ownership Event

[Diagram]

Entry points:

supplier-store create/update paths.
Event: UpsertInKycDocClaimedStatusEvent
Listener: UpsertInKycDocClaimedStatusEventListener
Handler: UpsertInKycDocClaimedStatusEventHandler

Detailed behavior:

When supplier-store receives a create/update request with GSTIN in KYC, it hashes the GSTIN and emits an ownership event.
Handler upserts kyc_doc_claimed_status:
- doc_sha
- kyc_doc_type
- supplier_id
- ownerShipState=CLAIMED
- updated_by
If the supplier was previously marked delinked in gst_fraud_supplier, the handler clears delinked state.

Blocking impact:

This flow does not directly deactivate suppliers.
It is important evidence for GST ownership and delink recovery.

Flow 7: GSTIN OTP Toggle / Delink Fraud Event

[Diagram]

Event:

GstinOtpVerificationToggleOrDelinkedEvent
Listener: GstinOtpVerificationToggleEventListener
Handler: GstinOtpVerificationToggleOrDelinkedEventHandler

Trigger sources:

Supplier update where gstinOtpVerificationStatus changes.
Supplier delete/update with isDelinked=true.
Supplier-creation async op listener for update flows.
Operational scripts that reset OTP status or trigger OTP banner.

Detailed behavior when OTP is true:

Get all suppliers using the same GSTIN.
Treat the verifying supplier as genuine.
Every other supplier using that GSTIN is:
- marked GST fraud
- deactivated with GST fraud metadata
- assigned gstinOtpVerificationStatus=false
- pushed to fraud platform through FraudGstSupplierEvent
Genuine supplier is marked non-fraud.
GSTIN ownership state becomes CLAIMED.
If GST KYC is approved, the genuine supplier can be marked valid again.

Detailed behavior when delinked:

Supplier fraud status is updated with delinked state.
GSTIN ownership state becomes INITIATED.
GST OTP verification pending communication/banner can be triggered.

Blocking impact:

This is one of the main GST Fraud deactivation paths.
It is different from GST-invalid inactive-GSTIN batch deactivation.

Flow 8: Admin Delink Or Fraud Marking

[Diagram]

Entry points:

Supplier update/delete through supplier-store admin APIs.
Can be reached through supply-orchestrator admin update path.

Detailed behavior:

If request carries isDelinked=true, supplier-store forcibly sets gstinOtpVerificationStatus=false.
The update/delete path emits GstinOtpVerificationToggleOrDelinkedEvent.
The handler marks delinked/fraud metadata and can move GST ownership state to INITIATED.

Blocking impact:

This can make a supplier invalid/fraud even without GST portal inactive status.
For PFS, this should be separated from batch GST-invalid blocks.

Flow 9: GST Invalid Batch Deactivation

[Diagram]

Entry points:

Scheduler: GstSupplierBatchProcessingScheduler
Service: GstSupplierBatchProcessingServiceImpl
Listener: GstSupplierProcessingListener
Handler: GstSupplierProcessingHandlerImpl

Detailed behavior:

Scheduler reads GST model output from Presto.
Progress is tracked in GstCronProgressEntity.
Each supplier is pushed to GST supplier processing MQ.
Handler fetches supplier with KYC and gst_invalid_banner attribute.
Non-GST or missing-GSTIN suppliers are skipped.
GSTIN is revalidated through supplier-UMS verifyGstinStatus.
Decision tree:
- GST active + supplier blocked: banner true, so supplier can reactivate.
- GST active + supplier unblocked: banner false or no change.
- GST inactive + supplier blocked: banner true.
- GST inactive + supplier unblocked: deactivate and banner true.
Deactivation reason:
- GST validation failed - Inactive GSTIN
Valid change type:
- temporary delete (validChangeType=2)

Blocking impact:

This is the clean GST-invalid blocking flow.
It should be analyzed separately from GST fraud, QC fraud, or manual admin deactivation.

Flow 10: GST Invalid Self-Serve Reactivation

[Diagram]

Entry points:

POST /api/v1/supplier/gst-invalid/blocked/reactivation/banner-status
POST /api/v1/supplier/gst-invalid/blocked/reactivate
Service: GstInvalidSupplierReactivationServiceImpl
Supplier panel banner: GSTIN reactivation banner.

Detailed behavior:

Banner status reads supplier attributes:
- gst_invalid_banner
- last_reactivation_attempt_at
If banner is false, account is treated as active/no reactivation needed.
Freeze period is configured through gst.reactivation.freeze-period-minutes; prod docs mention 1440 minutes.
Reactivation validates the existing GSTIN through supplier-UMS.
If GST validation API errors, no reactivation happens.
If GST is active:
- supplier is updated with valid=true
- restoreProducts=true
- qcStatusId=1
- gst_invalid_banner=false
If GST is still inactive:
- supplier stays blocked
- attempt timestamp is updated
- freeze period starts.

Blocking impact:

This is the recovery path only for GST-invalid blocks.
It does not apply to all GST fraud/QC fraud blocks unless those suppliers also have the GST-invalid banner flow enabled.

Flow 11: NGST To GST Transition

[Diagram]

Entry points:

supplier-UMS:
- POST /api/supplier-ums/v1/gst/transition/validate-gstin
- POST /api/supplier-ums/v1/gst/transition/create-supplier
supplier-store:
- POST /api/v1/gst-transition/process
- POST /api/v1/gst-transition/get/new-supplier
Scheduler: EnableGstTransitionScheduler

Detailed behavior:

Non-GST/enrolment supplier validates a new GSTIN.
GSTIN must be active and not already linked.
PAN from GSTIN is compared with existing supplier PAN.
SurePass GST contacts response is fetched and cached for later KYC.
New GST supplier is created.
supplier_gst_transition records old supplier, new supplier, GSTIN, PAN, and same-PAN flag.
gst_transition=true attribute is set on old and new suppliers.
If PAN is the same, old supplier is deactivated with GST transition reason.
If PAN differs, both old and new suppliers may remain active.

Blocking impact:

Deactivation here is regulatory/account-transition, not GST-invalid or GST fraud.
It can still appear as supplier blocked if old supplier is inspected without transition context.

Flow 12: Admin KYC Refresh

[Diagram]

Entry point:

supplier-ums: POST /api/supplier-ums/v1/supplier/kyc/refresh
Controller: AdminPanelSelfServeController
Service: AdminPanelSelfServeServiceImpl

Detailed behavior:

Fetches supplier KYC from supplier-store.
Revalidates current GSTIN/EID without duplicate check.
Rejects if GST type changes.
Rejects if GST registered state changes.
For ENROLMENT:
- updates GST/EID verification response if changed.
For GSTIN:
- fetches registered mobile/email.
- updates registered contacts and verification response if changed.

Blocking impact:

Does not directly deactivate.
Can affect later OTP/contact verification and final GST status.
Useful when vendor data was stale or GST registered contacts were missing.

Flow 13: Supplier KYC Contact Sync Scheduler

[Diagram]

Entry point:

supplier-store: SupplierKycMobileSyncSchedularService

Detailed behavior:

Finds supplier KYC rows created in a date window where GST registered mobile is a static placeholder.
Excludes ENROLMENT.
Calls SurePass for GST registered contacts.
Updates registered mobile/email if real mobile is available.

Blocking impact:

Does not directly deactivate.
Can change whether future OTP/contact checks pass or require supplier action.

Flow 14: Bulk Fraud GST Operational Scripts

[Diagram]

Entry points:

POST /supplier/fraud-gst-sync
POST /supplier/set-gst-otp-verification-to-false
POST /supplier/set-valid-to-false
POST /supplier/remove-fraud-from-gsts
POST /supplier/kyc-doc-claimed-status-backfill
POST /api/v1/internal/gstin/sha/creation

Detailed behavior:

fraudGSTSync:
- Finds supplier entity GSTIN values marked as fraud GST.
- Syncs those values into supplier_legacy.
- Does not itself deactivate.
setGstOtpVerificationToFalse:
- Sets supplier KYC OTP verification false.
- Updates gst_fraud_supplier.delinkedTime.
setValidToFalse:
- Reads gst_fraud_supplier.
- If delinkedTime exists and verificationTime is null, active suppliers are set valid=false.
- Adds GST fraud deactivation metadata.
removeFraudFromGsts:
- Removes fraud prefix from GSTIN in KYC and legacy records.
- Recomputes PAN.
- If supplier is active and qcStatusId=1, triggers OTP banner logic, which can set supplier invalid/delinked unless skip rules apply.
kycDocClaimedStatusBackfill:
- Backfills kyc_doc_claimed_status.
- Creates/updates gst_fraud_supplier rows for fraud GST cases.
createGstinSha:
- Backfills GSTIN SHA for KYC lookup.

Blocking impact:

setValidToFalse and removeFraudFromGsts can directly or indirectly deactivate suppliers.
These are operational paths and can explain historical cohorts that do not match live product flows.

Flow 15: Manual QC Fraud Status

[Diagram]

Entry point:

Admin supplier update path through supply-orchestrator and supplier-store.

Detailed behavior:

qcStatusId=13 maps to Fraud supplier deactivation.
This QC status can be updated independently from valid.
RCA evidence in this workspace showed suppliers with:
- valid=1
- validChangeType=1
- qcStatusId=13
That means a supplier can look fraud-blocked in QC/status surfaces while still account-active in supplier validity fields.

Blocking impact:

Must be separated from GST-invalid and GST fraud ownership flows.
For PFS, check both valid and qcStatusId, not just status label.

Flow 16: Read And UI Gating Flows

[Diagram]

Read APIs and UI surfaces:

validate/gstin
/supplier/gst/supplier-ids
/is-delinked/gstin
/supplier/fraud-gst-status
/supplier/is-delinked
GST-invalid banner status API
Supplier panel GSTIN reactivation banner
Ads/promotions/cataloging feature gates based on GST type.

Detailed behavior:

These surfaces usually do not mutate state.
They determine whether a supplier sees:
- GST-invalid reactivation banner
- GST OTP pending state
- GST fraud status
- non-GST restrictions on ads/promotions
- GST transition banner

Blocking impact:

Important for explaining user experience.
Usually not the source of the block.

Flow 17: GST Transition Enablement Scheduler

[Diagram]

Entry points:

Scheduler: EnableGstTransitionScheduler
Service: EnableGstTransitionService
Manual trigger: POST /api/v1/scheduler/enable-gst-transition/automation
Attribute key: enable_gst_transition
Input table/model: gold.ngst_transition_tech_input

Detailed behavior:

Supplier-store periodically reads supplier IDs and pill_show_flag from Presto.
Values 1 and true map to supplier attribute enable_gst_transition=true; everything else maps to false.
Attribute updates are batched through AttributeOrchestratorService.
Supplier panel/growth reads supplier and experiment config to decide whether GST transition entry points are visible.

Blocking impact:

This does not deactivate or reactivate a supplier.
It can hide the NGST-to-GST transition path for an otherwise eligible supplier.
For PFS, this matters when a non-GST supplier cannot start transition, but it is not a GST-invalid/Fraud block.

Flow 18: Assisted / LeadSquared Supplier Creation

[Diagram]

Entry point:

Manager: LeadSquaredManager
Registration source: LEADSQUARED
Uses the same step services as SSR:
- GstDetailsStep
- BankDetailsStep
- PickupAddressStep
- SupplierCreationStep
- PostSupplierCreationStep

Detailed behavior:

Internal/assisted onboarding builds user, GST, bank, pickup address, and supplier creation requests from a LeadSquared payload.
GST validation runs before supplier creation through GstDetailsStep.
Bank and pickup validation use GST verification response and GST type, same as normal SSR.
For non-IN country, KYC is auto-approved.
For IN country, registered GST contacts are fetched/validated and KYC is enriched before supplier-store create.
Post-create operations include moderator mapping, emails, user logger update, and downstream creation actions.

Blocking impact:

This can block assisted onboarding for the same GST reasons as normal registration: invalid GSTIN, inactive GSTIN, duplicate GSTIN, taxpayer-type rejection, provider failure, bank/GST mismatch, or pickup/GST mismatch.
It is not a separate post-registration GST-invalid deactivation flow.
PFS should include registration source/moderator when segmenting rural sellers.

Flow 19: Registration Fraud Score And Delinked GST Check

[Diagram]

Entry points:

FraudStatusFlagServiceImpl
FraudStatusFlagHelperService
Fraud DB scheduler:
- FraudSuppliersDbSyncingScheduler
- FraudSuppliersDbSyncingSchedulerHelper

Detailed behavior:

UMS maintains fraud_suppliers_data from Presto fraud model output.
The fraud DB sync job fetches supplier IDs from supplier-store with KYC data, then stores identifiers such as pickup address, account number, device ID, email, supplier identifier, pincode, and IP address.
During registration/KYC enrichment, UMS calculates a fraud score using:
- device ID match
- IP address match
- bank account match
- email/address score when available
- delinked GSTIN check through supplier-store isGstinDelinked
If the GSTIN is delinked, that reason has higher priority than duplicate bank account.
The result is persisted in user_fraud_status_scores.
Only RED is treated as fraud by this service.

Blocking impact:

This is a registration-time fraud-classification path, not the same table as supplier-store gst_fraud_supplier.
It can produce platform-level fraud signals after supplier creation.
For GST-invalid/Fraud analysis, this explains sellers blocked because they reused a previously delinked GSTIN during onboarding.

Flow 20: Warehouse Onboarding GST Ownership Check

[Diagram]

Entry points:

Supplier-store warehouse onboarding in SupplierCrudService
v4 path in SupplierServiceV4Impl

Detailed behavior:

Warehouse onboarding first validates that the parent supplier is valid and not already a warehouse.
It checks registered address quality before proceeding.
It hashes the warehouse GSTIN and looks it up in kyc_doc_claimed_status.
If the GSTIN is already claimed by another supplier ID, onboarding fails with Gstin already claimed by other supplier.
If the GSTIN is unclaimed or already claimed by the parent supplier, the flow continues to supplier upsert for warehouse/child supplier creation.

Blocking impact:

This blocks warehouse onboarding, not the parent supplier account.
It can look like GST ownership/fraud from an operational lens because it uses the same ownership table.
It does not directly set supplier.valid=false or create gst_fraud_supplier.

Flow 21: Supporting GST Validation And Control APIs

[Diagram]

Entry points:

POST /api/supplier-ums/v1/check-gst-exist
POST /api/supplier-ums/v1/check-enrolment-exist
POST /api/supplier-ums/v1/gstin/verify-status
POST /api/v1/gst/gst-verification/fetch
POST /api/supplier-ums/v1/user/gst/toggle-verification
POST /api/supplier-ums/v1/supplier/gst/registered-details

Detailed behavior:

check-gst-exist and check-enrolment-exist rate-limit the user and ask supplier-store whether the document is already linked.
verify-status revalidates a GSTIN and returns ACTIVE, INACTIVE, or API error. GST-invalid batch and reactivation depend on this style of status check.
fetch returns the raw GST/EID verification response for controlled internal use.
toggle-verification switches the configured primary GST verification provider flag.
registered-details retries GST registered contact fetch when supplier-store has missing registered mobile/email. It can then update supplier KYC through supplier-orchestrator.

Blocking impact:

Most of these APIs do not directly block a supplier.
verify-status feeds blocking/recovery decisions in GST-invalid flows.
registered-details can change OTP/final GST status inputs if registered contact data was missing.
Provider toggle can change behavior globally and should be checked when provider-level outages or mismatched GST statuses appear in PFS windows.

Recommended PFS Segmentation

Use this order when classifying rural sellers found under GST-invalid/Fraud:

[Diagram]

Suggested checks:

Check account state:
- valid
- validChangeType
- deactivation reason/date/by
- deactivation metadata
Check QC state:
- qcStatusId
- supplier_qc_statuses
- status_change_logs
Check GST-invalid:
- gst_invalid_banner
- last_reactivation_attempt_at
- deactivation reason contains inactive GSTIN
Check GST fraud:
- gst_fraud_supplier.is_fraud_gst
- gst_fraud_supplier.is_delinked
- delinked_time
- verification_time
- gstin_otp_verification_status
Check GST ownership:
- kyc_doc_claimed_status.doc_sha
- ownerShipState
- mapped supplier ID
Check duplicate GSTIN:
- supplier IDs for same GSTIN SHA
Check GST transition:
- supplier_gst_transition.old_supplier_id
- new_supplier_id
- is_same_pan
Check GST transition enablement:
- supplier attribute enable_gst_transition
- supplier panel experiment config
- Presto model row from gold.ngst_transition_tech_input
Check registration fraud scoring:
- user_fraud_status_scores.fraud_status_flag
- fraud_reasons_value
- delinked GSTIN reason
- duplicate bank account reason
Check warehouse onboarding ownership failures:

kyc_doc_claimed_status.doc_sha
requested warehouse GSTIN SHA
parent supplier ID vs claimed supplier ID

Check supporting validation controls:

gstin_search_flag
GST provider toggle history
verify-status API error windows
registered-contact retry/update logs

Check operational scripts:

updated_by values like backfilled
deactivation metadata moderator/client IDs
status change logs around script execution windows

Flow-To-Block Mapping

Flow	Directly blocks supplier?	Typical label
Registration GSTIN save	No, blocks registration	Invalid/inactive GSTIN at onboarding
Registration KYC	Can create invalid supplier	KYC pending/rejected
GST registered contact OTP	Indirect	GST OTP pending
Supplier create/update claim event	No	GST ownership metadata
GSTIN OTP toggle/delink event	Yes	GST fraud/delink
Admin delink	Yes/indirect	GST fraud/delink
GST invalid batch	Yes	GST-invalid
GST invalid reactivation	Unblocks	Reactivated/GST active
NGST-to-GST transition	Yes for old supplier if same PAN	GST transition
Admin KYC refresh	No	KYC refreshed
KYC contact sync	No	Contact updated
Bulk scripts	Yes for some scripts	GST fraud/backfill
Manual QC fraud status	Can label/block depending fields	Fraud supplier deactivation
UI/read gating	No	Banner/feature hidden
GST transition enablement scheduler	No	Enables/hides transition CTA
Assisted LeadSquared creation	No post-registration block	Assisted onboarding GST/KYC rejection
Registration fraud score and delinked GST check	Indirect	Fraud/red onboarding signal
Warehouse onboarding GST ownership check	No parent block	Warehouse creation rejected
Supporting GST validation/control APIs	Indirect	Status check/contact retry/provider behavior