SEBI issued a consultation paper proposing significant changes to the existing Straight Through Processing (STP) framework used in Indian capital markets for processing transactions and exchange of messages such as Electronic Contract Notes (ECNs) among stock brokers, custodians, and institutional investors. SEBI observed that the present architecture, which routes inter-SSP communications through a centralized STP Hub, results in higher latency, additional transmission costs, operational inefficiencies, concentration risk, and potential single point of failure. Based on traffic analysis between April 2025 and December 2025, SEBI noted that over 95%-99% of STP messages were routed through a single STP Service Provider (SSP), thereby increasing concentration risk. To address these issues, SEBI proposed replacing the centralized STP Hub with a decentralized API-based connectivity framework between SSPs. Under the proposed structure, SSPs would communicate directly through standardized APIs while ensuring authenticity, integrity, and non-repudiation of messages. SEBI stated that the proposed framework would reduce latency and costs, improve scalability, strengthen operational resilience, and support institutional trading volumes without requiring system changes for STP users such as brokers, custodians, and institutional investors. The consultation paper also proposes optional API-based communication between STP users serviced by the same SSP to reduce manual intervention and human errors. SEBI further proposed revised operational guidelines, obligations, code of conduct, eligibility conditions, and standard operating procedures for STP Service Providers through draft guidelines titled “SEBI (STP Service Providers and associated API-based connectivity between STP Service Providers) Guidelines, 2026.” Public comments on the proposal have been invited until June 9, 2026.
Securities and Exchange Board of India
Consultation Paper: Easing of framework for Straight Through Processing (STP) of trades
SEBI- May 19, 2026 | Reports : Reports for Public Comments
Click here to provide your comments
1. Objective:
The objective of the consultation paper is to seek feedback on the enhancements in the existing Straight-Through Processing (STP) Framework to reduce the latency, costs and enhance service delivery for market participants.
2. Background
2.1. STP automates the end-to-end processing of transactions of the financial instruments. It involves use of a single system to process or control all elements of the work-flow of a financial transaction. STP is used for various messages being exchanged across market participants like Stock Brokers, Custodians and/or Institutional investors and includes Electronic Contract Note (ECN), amongst other messages.
2.2. SEBI vide circulars dated February 3, 2004, February 25, 2004, April 1, 2004 and May 26, 2004 prescribed framework for implementation of STP in Indian Capital Markets.
3. Existing STP architecture involving STP Hub
3.1. The schematic diagram below provides sequence of information flow involving STP users i.e. stock broker communicating messages through sender STP Service Provider (SSP) and Custodian / Institutional Investor communicating through receiver SSP.
4. Issues with current STP framework
4.1. As can be seen in the diagram above, different SSPs for each STP user leads to transmission of information through an STP hub. This typically takes more time as compared to direct flow through common SSP and also results into higher transmission charges (due to STP Hub charges). Further, certain value added services by SSPs would not be feasible for information traversing through STP hub.
4.2. STP users typically upload and download files through the interface provided by SSPs. This can be prone to human error/dependency.
4.3. Based on the analysis of current traffic pattern for STP framework for the time period April 1, 2025 to December 31, 2025, it is noted that over 95%-99% of STP messages are routed through a single SSP. This heightens concentration risk. Further, as inter SSP messages flow through a single entity (i.e. STP Hub), there is a possibility of single point of failure while processing messages of multiple SSPs.
4.4. Given the cost and latency implications of the messages flowing through STP Hub, there could be an incentive (in terms of low latency and cost) for market participants to consolidate their activities with one SSP, thereby aggravating the concentration risk associated with single significant SSP. At the same time, miniscule volume of traffic currently flowing through the STP Hub suggests that it is no longer serving its intended purpose of broad-based interoperability, necessitating a more decentralized connectivity model.
5. Proposed changes in the STP framework:
5.1. It is proposed to do away the existing STP Centralized Hub for message transfer between different SSPs. This would be replaced by a direct Application Programming Interface (API) based framework between the SSPs.
5.2. The approach would require the SSPs serving different STP users to enable standardized API endpoints, adhering to agreed-upon protocols and data formats, thus enabling seamless and secure exchange of messages and data without routing through a centralized hub. This would also enhance scalability and cost-effectiveness of STP framework while supporting the transaction volumes of institutional trading.
5.3. The aforesaid proposal would not entail any change at the end of the STP users (i.e. stock brokers, fund houses, custodians etc.) and would likely encourage more SSPs to participate, thereby mitigating the concentration risk with single large SSP and improving value added services by SSPs to STP users.
5.4. Following is the process flow for the proposed framework:
5.4.1. The step by step detail of information flow with different SSPs for stock broker (i.e. sender SSP) and Institutional Investor / Custodian (i.e. receiver SSP), in the API based STP framework is as under:
5.4.1.1. Upload of Electronic Contract Note (ECN) by Stock Broker: The Stock Broker initiates the process by uploading the ECN to the first STP Service Provider (SSP-1) – servicing the broker.
5.4.1.2. Transmission of ECN: SSP-1 transmits the ECN data through an API-based Connectivity layer to the second STP Service Provider (SSP 2) – which services the Institutional investor / Custodian.
5.4.1.3. ACK: SSP-2 sends back Acknowledgements (ACK) through the API layer to SSP-1, confirming receipt of the data.
5.4.1.4. ECN Transmission & Receive ACK: SSP 2 transmits the ECN to the Institutional Investor. Once received, the Institutional Investor sends an acknowledgement back to SSP-2.
5.4.1.5. Broker receives ACK: Finally, SSP 1 sends the final acknowledgement back to the Broker, completing the communication loop.
5.4.2. As can be seen, compared to the STP hub based architecture (presented at para 3 above), the proposed API based STP framework requires fewer number of message exchanges among the entities involved.
6. Proposal:
6.1. To ensure Ease of Doing Business, a transition is proposed from existing STP Hub based architecture to decentralized API based structure. While resulting in latency and cost advantage, the proposal would not require any system change for the STP users (i.e. stock brokers / Institutional Investors / Custodians).
6.2. To minimize human error and to increase ease of operations for STP users while strengthening security, it is proposed to introduce an optional API-based message exchange for different STP users of same SSP. This would be in addition to the upload / download facility and would enable seamless, automated communication between STP users serviced by the same SSP.
Invitation for Public Comments
7.1. A draft circular incorporating the aforesaid proposals in the present STP guidelines is placed at Annex A for public comments. The comments/ suggestions should be submitted latest by June 9, 2026, through the online web-based form which can be accessed using the following link: https://www.sebi.gov.in/sebiweb/publiccommentv2/PublicCommentAction.do ?doPublicComments=yes
7.2. In case of any technical issue in submitting your comment(s) through the web based public comments form, you may email your comment(s) to Darshil Bhatt, DGM (darshilb@sebi.gov.in), Harshad Patil, AGM (harshadp@sebi.gov.in) and mrd tpd@sebi.gov.in. While sending the email, kindly mention the subject as “Easing of framework for Straight Through Processing (STP) of trades”
Issued on: May 19, 2026
Annex A
Draft Circular
SEBI/HO/MRD/TPD-1/P/CIR/2026/ XXX | MM DD, 2026
To
All Stock Exchanges,
All Clearing Corporations,
All Depositories,
All Registered STP Service Providers, STP Centralized Hub
Sir/Madam,
Easing of Framework for Straight Through Processing (STP) of Trades
1. SEBI prescribed guidelines for regulating the services and infrastructure set-up in respect of Straight Through Processing vide circular dated May 26, 2004 (SEBI (STP Centralised Hub and STP Service Providers) Guidelines, 2004) and other relevant circulars.
2. STP is used for various messages being exchanged across market participants like Stock Brokers, institutional investors and custodians and includes ECN amongst other messages.
3. Based on reference received from market participant and in order to enhance operational efficiency, it has been decided to do away with the existing centralized Hub for message transfer between different SSPs. This would be replaced by a direct Application Programming Interface (API) based framework between the SSPs. The proposal has been discussed with STP Service Provider and Technical Advisory Committee of SEBI.
4. The diagrammatic representation of the revised STP Framework is as under:
5. SSPs shall ensure authenticity, integrity and non-repudiation of the message being transmitted.
6. Industry Standard Forum (ISF) of Market Infrastructure Institutions will formulate the Standard Operating Procedure applicable for SSPs and ensure optimum operational modalities such as messaging standards / message formats, in consultation with SEBI.
7. Additionally, ISF shall submit a plan to SEBI within a period of three months for an optional API based information exchange between different STP Users serviced by same SSP. This will be in addition to the manual upload and download of messages (such as ECN) by STP Users.
8. Accordingly, the relevant provisions of the Chapter 2 and Chapter 5 of the SEBI Master Circular for Stock Exchanges & Clearing Corporations dated December 30, 2024 stand modified as per the details provided in Annexure A-1.
9. The circular would become effective from DD MM YY.
10. This circular is being issued in exercise of powers conferred under Section 11 (1) of the Securities and Exchange Board of India Act, 1992 to protect the interests of investors in securities and to promote the development of, and to regulate the securities market.
Yours faithfully,
Annexure A-1
Chapter 2 of SEBI Master Circular
4. STRAIGHT THROUGH PROCESSING
4.1. Mechanism
4.1.1. Straight Through Processing (“STP”) is generally understood to be a mechanism that automates the end to end processing of transactions of financial instruments. It involves use of a system to process or control all elements of the work flow of a financial transaction, what are commonly known as the Front, Middle, Back office and General Ledger. In other words, STP allows electronic capturing and processing of transactions in one pass from the point of order origination to final settlement. STP thus streamlines the process of trade execution and settlement and avoids manual entry and re-entry of the details of the same trade by different market intermediaries and participants. Usage of STP enables orders to be processed, confirmed, settled in a shorter time period and in a more cost effective manner with fewer errors. Apart from compressing the clearing and settlement time, STP also provides a flexible, cost effective infrastructure, which enables e-business expansion through online processing and access to enterprise data.
4.1.2. It has been mandated that all the institutional trades executed on the stock exchanges would be processed through the STP System.
4.2. The system flow of the STP framework
4.2.1. While several STP Service Providers provide STP service to the market participants to resolve the issue of inter-operability between the STP Service Providers it is decided in consultation with the stock exchanges and the STP Service Providers that would be connected with API-based connectivity between STP Service Providers and the messages between STP Service Providers shall be transmitted through standardised APIs.
4.2.2. The system flow for the STP framework shall be as follows:
4.2.2.1. STP user intending to send an instruction would send the message to his STP service provider while ensuring authenticity, integrity and non-repudiation.
4.2.2.2. The sender STP service provider would verify the signature of the STP user and forward it to the recipient STP user, if the recipient STP user is availing services of the same STP service provider or the recipient STP service provider through an API-based connectivity if the recipient STP user is not with the same STP service provider. In such a case the STP service provider would be required to prepare a message as per the API-based connectivity between STP Service Providers prescribed message format, enclose the user’s message, and then send it to the SSP while ensuring authenticity, integrity and non-repudiation.
4.2.2.3.The STP Service Providers shall ensure the integrity of the message and authenticity of the sender (by way of say verification of signature of sending STP service provider and acknowledgment to the sending STP service provider)
4.2.2.4. The sender STP Service Providers would forward the message to the recipient STP Service Provider while ensuring authenticity, integrity and non-repudiation.
4.2.2.5. The recipient STP service provider on receipt of the message from the other SSP shall verify the signature of the sender, verify if the recipient STP user is associated with it and send an appropriate acknowledgment while ensuring authenticity, integrity and non-repudiation.
4.2.2.6. The recipient STP service provider shall forward the message to the recipient STP user. The recipient STP user would receive the message and verify the signature of the recipient STP service provider and sending STP user.
4.2.3. The PKI (Public key infrastructure) system for the interface shall be implemented at a later stage to ensure authenticity, integrity and non-repudiation.
4.2.4. The block diagram of the entire STP System is placed at Annexure I.
4.3. SEBI (STP service providers and associated API-based connectivity between STP Service Providers) Guidelines, 2026
4.3.1. SEBI in order to regulate the STP service is issuing the SEBI (STP service providers and associated API-based connectivity between STP Service Providers) Guidelines, 2026 (herein referred to as “STP Guidelines”) which also prescribe the Standard Operating Procedures (SOPs) between all the STP service providers, which will be developed by Industry Standard Forum (ISF) in consultation with SEBI specifies the eligibility criteria and conditions of approval for the STP service providers, obligations and responsibilities of the STP service providers and code of conduct for the STP service providers. The STP service providers shall abide by these Guidelines.
4.3.2. To prescribe contractual obligations between the STP service providers and to facilitate standardisation of service, an Standard Operating Procedure (SOP) between the STP service providers shall be developed by ISF of MIIs in consultation with SEBI while framing the SOP governing the STP Service Provider API architecture, the ISF shall ensure that:
1. Inputs from some of the users of STP service i.e. brokers, custodians and institutional investors are sought
2. The framework leverages technology to ensure complete
interoperatibility amongst SSPs to ensure that a user sending & receiving messages in interoperability model ( i.e. different SSPs at two ends) is not at disadvantageous situation as compared to another user operating in intraoperatibility (i.e. common SSP at both ends)
3. In addition of exchange of messages thru’ APIs, the SSPs shall also endeavour to share information amongst themselves related to various stages of a give message so that the interested user (e.g. broker) can actively follow up with the relevant counterparty (e.g. Institutional Investor, custodian) for necessary action.
4. SSPs shall follow the SOP prescribed by ISF of MIIs in consultation with SEBI.
4.4. Work flow for institutional investors1
4.4.1. SEBI in consultation with the STP service providers and the STP users has prescribed the transaction work flow for the STP system. All institutional investors shall follow the following transaction work flow on a mandatory basis:
4.4.1.1. A contract note in electronic form in the prescribed format asdecided by the ISF shall be issued by the broker & sent to the custodian and/ or the institutional investor.
4.4.1.2. In case the contract note is processed directly by the institutional investor, the institutional investor shall send the trade confirmation of acceptance or rejection of the contract note to the broker by using the appropriate messaging standard as finalized by the ISF. The custodian shall also send the confirmation of acceptance or rejection of such contract note to the broker using the appropriate messaging standard as finalized by the ISF.
4.4.1.3.In case the contract note is processed by the custodian on behalf of the institutional investor, the custodian shall send the confirmation of acceptance or rejection of the contract note to the broker by using the appropriate messaging standard as finalized by the ISF.
4.4.1.4. The institutional investor shall send settlement instructions to its custodian in messaging formats as finalized by the ISF to the custodian for predefined trade types.
4.4.1.5.The custodian shall confirm/ reject the execution of the settlement instructions to the institutional investor in specific messaging formats as defined by ISF.
4.4.1.6. It is clarified that if a message (for the activities mentioned above) is sent using the API-based framework from one user to another user, then the confirmation / rejection for such a message shall also be sent using the API-based framework.
4.4.2. ISF shall specify the messaging format which shall be followed by the market participants.
4.4.2.1. In order to bring in standardisation in the input of the identification codes in the prescribed messaging standards, it is clarified that the following codes shall be used by the various entities:
4.4.2.1.1. Brokers: SEBI registration number
4.4.2.1.2. Mutual Funds and schemes of Mutual Funds: SEBI registration number for Mutual Funds and Unique client code issued by the exchanges for schemes
4.4.2.1.3. FPIs: SEBI registration number for the Foreign Portfolio Investors (“FPIs”)
4.4.2.1.4. Custodians: SEBI registration number
4.4.2.1.5. STP service providers: PAN
4.4.2.1.6. Depositories and exchanges / clearing house / clearing corporation: PAN
4.4.2.1.7. Other Institutional Investors like financial institutions, banks etc.: Unique client code issued by the exchanges
4.4.2.2. All market participants shall issue the electronic contract note for institutional trades in the modified format.
4.4.3.The mandatory messaging formats for all institutional trades shall be specified by ISF and that the STP system shall be applicable for instructions / ECNs pertaining to all segments of exchanges.
4.4.4.The standard terms of contract as are required to be mentioned in the Contract Notes as per the Bye-laws and Regulations of exchanges, which are not contained in electronic contract notes, shall be incorporated in the Client Broker Agreement or where applicable, the Tripartite Agreement between the stock broker, AP and the client. The stamp duty in respect of the electronic contract notes shall be paid by the broker.
4.5. Any other clarifications, as deemed fit by ISF, may be issued to market in consultation with SEBI
4.6. Modifications in the prescribed messaging formats2
In order to integrate the STT in the STP system, it would be necessary to provide for necessary fields in the appropriate messaging standards. The messaging types shall incorporate the said data in demarcated message types as specified by ISF after deliberation with the STP service providers and SEBI.
4.7. Further, the API framework should support transmission of all mandatory fields in an Electronic Contract Note (ECN) or Institutional investors instruction to custodians.
Chapter 5 of SEBI Master Circular – Exchange traded Derivatives
14.9. Straight through Processing
14.9.1. Straight Through Processing (STP) is generally understood to be a mechanism that automates the end to end processing of transactions of financial instruments. It involves use of a system to process or control all elements of the work flow of a financial transaction, what are commonly known as the Front, Middle, Back office and General Ledger. In other words, STP allows electronic capturing and processing of transactions in one pass from the point of order origination to final settlement. STP thus streamlines the process of trade execution and settlement and avoids manual entry and re-entry of the details of the same trade by different market intermediaries and participants. Usage of STP enables orders to be processed, confirmed, settled in a shorter time period and in a more cost effective manner with fewer errors. Apart from compressing the clearing and settlement time, STP also provides a flexible, cost effective infrastructure, which enables e-business expansion through online processing and access to enterprise data.
14.9.2. To resolve the issue of inter-operability between the STP Service Providers, an API-based connectivity would be prescribed/formulated by ISF of MIIs between STP Service Providers in consultation with the stock exchanges and the STP Service Providers.
14.9.3. In view of the aforesaid developments, it has been decided that all the institutional trades executed on the stock exchanges would be mandatorily processed through the STP System. An institutional trade for the purpose of STP shall mean a trade which is settled through a custodian. Institutional trades where electronic contract note in the prescribed format is issued, no physical contract note (for such a trade) shall be issued by the brokers. The system flow of the STP framework would be as follows:
14.9.3.1. A STP user intending to send an instruction would send the message to his STP service provider after ensuring authenticity, integrity and non-repudiation.
14.9.3.2. The STP service provider would verify the signature of the STP user and forward it to the:
14.9.3.2.1. Recipient STP user, if the recipient STP user is availing services of the same STP service provider; or the
14.9.3.2.2. Recipient STP Service Provider through API-based connectivity between STP Service Providers if the recipient STP user is not with the same STP service provider. In such a case the STP service provider would be required to prepare a message as per the API-based connectivity between STP Service Providers prescribed message format, enclose the user’s message, ensure authenticity, integrity and non-repudiation while sending it to the Recipient STP Service Provider through API-based connectivity between STP Service Providers
14.9.3.3. On receipt of the message through the API, Recipient STP Service Provider would
14.9.3.3.1. verify the signature of the sending STP service provider only. 14.9.3.3.2. send an acknowledgment to the sending STP service provider.
14.9.3.4. The message would be forwarded through API-based connectivity between STP Service Providers to the recipient STP service provider after ensuring authenticity, integrity and non-repudiation of the message.
14.9.3.5. The recipient STP service provider on receipt of the message through an API-based connectivity between STP Service Providers shall verify the signature of the API, verify if the recipient STP user is associated with itself and send an appropriate acknowledgment to ensure authenticity, integrity and non-repudiation. The API would in turn forward the acknowledgment (received from the recipient STP service provider) duly signed to the sending STP service provider.
14.9.3.6. The recipient STP service provider shall forward the message to the recipient STP user. The recipient STP user would receive the message and verify the signature of the recipient STP service provider and sending STP user.
14.9.4. The PKI (Public key infrastructure) system for the interface shall be implemented at a later stage. The block diagram of the entire STP System is enclosed in ANNEXURE I.
14.9.5. SEBI in order to regulate the STP service is issuing the SEBI (STP service providers and associated API-based connectivity between STP Service Providers) Guidelines, 2026 (herein referred to as “SIP Guidelines”).
14.9.6. The STP guidelines prescribes the eligibility criteria and conditions of approval for the STP service providers, obligations and responsibilities of the STP service providers and code of conduct for the STP service providers. The STP service providers shall abide by these Guidelines. The guidelines are given as ANNEXURE II.
To prescribe contractual obligations between the STP service providers and to facilitate standardisation of service, an Standard Operating Procedure between the STP service providers shall be prescribed by ISF of MII in consultation with SEBI.
14.9.7. The messaging formats will be specified by ISF of MIIs in consultation with SEBI and STP providers.
14.9.8. In order to integrate the Securities Transaction Tax (STT) in the STP system, it would be necessary to provide for necessary fields in the appropriate messaging standards.
14.9.9. SEBI has extended the facility of issuance of ECNs as a legal document using Straight Through Processing (STP) to the equity derivatives segment also. The model contract note in electronic form and confirmation of electronic contract note shall be specified by ISF in consultation with SEBI. The Exchanges are advised to modify/amend their bye-laws, rules and regulations to;
Further, the MIIs and ISF should ensure that STP framework is scalable and can be made applicable across various segments available of transactions
14.9.13.1. Permit issuance of electronic contract note including all the standard pre-
printed terms and conditions as given in the physical contract note.
14.9.13.2. Permit authenticity, integrity and non-repudiation of the electronic contract note so as to make the modified format of the electronic contract note a valid legal document like the physical contract note.
14.9.13.3. Prescribe a standard format for the issuance of the electronic contract note.
ANNEXURES
Annexure I
Annexure II
SEBI (STP Service Providers and associated API-based connectivity between STP Service Providers) Guidelines, 2026
1) PRELIMINARY
1. These Guidelines shall be called the Securities and Exchange Board of India (STP service providers and associated API-based connectivity between STP Service Providers) Guidelines, 2026.
2. These Guidelines are being issued under section 11 of the Securities and Exchange Board of India Act, 1992 to promote the development of the securities market.
3. They shall come into force on DD MM YYYY
2) DEFINITIONS
(1) In these Guidelines, unless the context otherwise requires:-
(a) “Act” means the Securities and Exchange Board of India Act, 1992; (b) “Certifying Authority” means a certifying authority who has been granted a license under section 24 of the Information Technology Act, 2000;
c. “SEBI” means the Securities and Exchange Board of India established under Section 3 of the Act;
d. “STP” means straight through processing;
e. “API-based connectivity between STP Service Provider” means an infrastructure set-up by a person or entity for the purpose of rendering STP service by providing a platform for communication between different STP service providers;
f. “STP message” means and includes all the messages for electronic trade processing with a common messaging standard as may be defined by SEBI from time to time;
g. “STP service” means the setting up and maintaining of infrastructure to create an electronic communication network to facilitate information exchange with respect to securities market transactions between various market participants from the stage of trade initiation to final settlement through a STP system flow as may be determined by SEBI from time to time;
h. “STP service provider” means a person or entity providing STP service to STP users to the extent of conveying messages between a STP user and the API-based connectivity between STP Service Providers;
i. “STP user” means all the users of the STP service and includes such users as are stipulated by SEBI; and,
(2) Words and expressions used and not defined in these Guidelines, but defined in the Act or in the Securities Contracts (Regulation) Act, 1956 or in any rules or regulations made thereunder, shall have the meanings respectively assigned to them in such Acts, rules or regulations.
3) ELIGIBILITY CRITERIA FOR STP SERVICE PROVIDERS
1. No person shall act as a STP Service provider unless it obtains approval from SEBI to provide such service.
2. For the grant of a certificate of approval SEBI shall take into account the following:
i. whether the applicant is a person or entity with a minimum net-worth as may be prescribed from time to time.
ii. whether the applicant has adequate infrastructure facilities setup in India like office space, equipment and manpower with adequate experience in dealing in securities market and adequate expertise in providing necessary services and software solutions.
4) OBLIGATIONS AND RESPONSIBILITIES OF STP SERVICE PROVIDER
(1) The STP Service provider shall comply with the following :
i. The STP service provider shall at all times comply with the requirement of eligibility criteria, specified by SEBI.
ii. The STP service provider shall establish connectivity with the API Architecture before
providing STP service to its users.
iii. The STP service provider shall maintain the necessary details of the STP users connected with it and have a facility of sharing with other STP service providers through API Architecture for the purpose of creating and maintaining a directory of STP service providers and STP users in case of inter-SSP transfer of messages.
iv. The STP service provider shall comply with the minimum specifications specified by the SOP laid down by ISF and as may be mutually agreed upon.
v. The STP service provider shall abide by the service standards as may be specified from time to time.
vi. The STP service providers shall deliver a consistent and secure communication platform and shall establish continuous connectivity through the API Architecture to the best of its ability.
vii. The STP service provider shall ensure that the message sent through the API Architecture is in the prescribed messaging standard.
viii. The STP service provider shall confirm authenticity, integrity and non-repudiation of all messages submitted through the API Architecture. The STP service provider shall keep complete track of the flow of messages for record and audit.
ix. The STP service providers may charge reasonable fees from the STP users.
x. The STP service provider shall exchange messages between other STP service providers only through the API Architecture. Provided that in force majeure measures or any other circumstances due to which the connectivity of the API Architecture is not available, the STP service providers after mutual discussion may exchange messages directly among themselves for such period.
xi. The STP service provider shall enter into an agreement with all its STP users which shall clearly stipulate the fees chargeable by SSPs, obligations of SSPs (sending SSP and receiving SSP), compliance with laws and regulatory stipulations, service changes and prior intimation, if any, validity, termination clauses, governing law, amongst other clauses.
xii. The STP service provider shall maintain a directory of the STP users connected to it.
xiii. The STP service provider shall maintain a complete record of the flow of messages handled. The records of the STP service provider shall be open for inspection by SEBI or any other person duly authorised by SEBI for this purpose.
xiv. The STP service provider shall ensure that the message from the STP user is in the specified messaging format.
xv. The STP service provider shall promptly deliver messages to and from the STP user.
xvi. In respect of inter STP service provider messages, the STP service provider shall perform all actions to the best of its ability in the same manner, diligence, speed and with all checks and balances as if the message is to be delivered / received by the same service provider.
xvii. Contract notes issued by brokers should be pre-screened by its SSP with respect to static details like UCC amongst other static details to reduce fail rates and prevent avoidable load on the overall framework. The UCC and static details should be shared by the SSP of Institutional Investor with the other SSPs (who may service multiple brokers executing trades on behalf of the Institutional Investor) so that they can perform the pre-screening.
(2) Nothing in these guidelines shall exempt the STP service provider from discharging any obligations placed on it by any law, regulations and guidelines.
5) CONDITIONS OF APPROVAL FOR STP SERVICE PROVIDERS
(1) Terms of approval:
i. The approval by SEBI shall be for an initial period of three years for STP service providers and must be renewed periodically.
ii. The STP service provider must ensure continuous validity of approval by SEBI in order to function as a STP service provider.
iii. The Board shall have the right to suspend / cancel the approval of the STP service provider in case of violation of the terms of the guidelines.
6) CODE OF CONDUCT FOR STP SERVICE PROVIDERS
Every STP service provider shall abide by the Code of Conduct as specified in Schedule I.
7) Standard Operating Procedure
The STP service provider shall follow Standard Operating Procedure (SOP) which shall be stipulated by ISF. While framing the rules governing the STP Service Provider and API architecture, the Industry Standards Forum (ISF) shall ensure that such SOP is based on clearly defined service-level standards, performance benchmarks, and operational resilience requirements. The SOP shall be structured to maintain a level playing field among STP Service Providers and shall be driven by objective service-quality parameters, without being influenced by market concentration or dominance of any STP Service provider.
SCHEDULE I
CODE OF CONDUCT FOR STP SERVICE PROVIDERS (Clause 6 of the Annexure II – Guidelines)
a. The STP service provider shall render at all times high standards of service, exercise due diligence, ensure proper care and exercise independent professional judgment.
b. The STP service provider shall disclose to the clients its possible sources or potential areas of conflict of duties and interest and provide unbiased services.
c. The STP service provider herein agrees and undertakes to perform its duties as a STP service provider with the highest standards of integrity and fairness in all its dealings.
d. The STP service provider shall abide by the obligation as specified under these Guidelines and the terms of the agreement entered into by the STP service provider with the STP users.
e. The STP service provider shall maintain true and correct record of the messages processed by it under the scheme and in particular the records in respect of :-
i. the STP users
ii. the messages exchanged within the same STP service provider
iii. the messages exchanged with other STP service providers through the API-based connectivity between STP Service Providers
f. The STP service provider shall ensure that the message is not misused or tampered with while in its possession.
g. The STP service provider shall maintain confidentiality of information about its users and shall not divulge the same to other clients, the press or any other interested party except in accordance with law or as per the directions of any court of law.
h. The STP service provider shall abide by all the directives as may be issued by Securities and Exchange Board of India from time to time as may be applicable to the STP service provider.
Notes:
1 Ref.No. DNPD/Cir-25/04 dated June 10, 2004
2 Ref. No. DNPD/Cir-28/04 dated September 28, 2004
