OCO, OTO, OTOCO உத்தரவு உறவுகளை இந்திய வாசகர் எப்படிச் சரிபார்ப்பது

நிபந்தனை ஆர்டர் என்பது ஏதோ ஒரு பரிமாற்றத் தளத்தின் தனிச்சிறப்பு வசதி அல்ல; அது ஒரு பொதுவான execution அமைப்பு. இதன் அடிப்படை வடிவங்கள் மூன்று. முதலாவது, இரண்டில் ஒன்று: எதிர் திசைகளில் இரு ஆர்டர்கள் ஒரே நேரத்தில் சந்தையில் நிற்கும்; அவற்றில் ஒன்று நிறைவேறியவுடன் மற்றொன்று உடனே ரத்தாகும். இலாபம் எடுக்கும் விலையையும் நஷ்டத்தை நிறுத்தும் விலையையும் ஒரே சமயத்தில் வைக்க இது பயன்படுகிறது.

இரண்டாவது வடிவம், முன்நிபந்தனைக்குப் பின் தூண்டுதல்: முதல் ஆர்டர் முழுமையாக நிறைவேறிய பிறகுதான் இரண்டாவது ஆர்டர் சந்தைக்கு அனுப்பப்படும்; அதுவரை அது காத்திருப்பு நிலையில் மட்டுமே இருக்கும், order book-ல் இடம் பிடிக்காது. மூன்றாவது வடிவம், முன்நிபந்தனைக்குப் பின் இரண்டில் ஒன்று: முதல் ஆர்டர் நிறைவேறியவுடன் ஒன்றுக்கொன்று முரணான இரு தொடர் ஆர்டர்கள் ஒரே சமயத்தில் உருவாகும் — அதாவது முந்தைய இரு வடிவங்களையும் இணைத்த கட்டமைப்பு.

இந்த மூன்றுக்கும் தளங்கள் ஒரே பெயரை வைப்பதில்லை. சில இடங்களில் OCO, OTO, OTOCO என்ற சுருக்கங்கள்; வேறு சில இடங்களில் conditional order, planned order, take profit / stop loss என்ற தனித்தனி நுழைவுகள். பெயர் மாறினாலும் இயங்கு தர்க்கம் மாறுவதில்லை. மூன்று கேள்விகளுக்கு விடை கிடைத்தால் எந்தத் தளத்தின் ஆவணத்தையும் ஒரே முறையில் வாசிக்கலாம்: எந்த ஆர்டர் முதலில் matching-க்குச் செல்கிறது; தொடர் ஆர்டர் எந்த நிகழ்வின் பேரில் உருவாக்கப்படுகிறது; எந்த நிகழ்வு மற்றொரு leg-ஐ ரத்து செய்கிறது. இந்தக் கேள்விகளை மனதில் வைத்தே அடுத்த பகுதிகள் அதிகாரப்பூர்வ Spot ஆவணத்தின் field பெயர்கள், status மதிப்புகள் மற்றும் filter வரம்புகளுடன் ஒப்பிடப்படுகின்றன.

OTO என்பது One Triggers the Other. இங்கு working leg முதலில் வேலை செய்கிறது; pending leg அடுத்த கட்டத்திற்காக பதிவு செய்யப்பட்டிருந்தாலும் முன் உத்தரவு முழுவதும் நிறைவேறும் வரை சாதாரண வேலை நிலையில் இருக்காது. முதல் உத்தரவு பத்து unit என்றால் நான்கு unit fill ஏற்பட்டதைக் கொண்டு இரண்டாவது leg நான்கு unit அளவில் தொடங்கிவிட்டது என்று ஊகிக்கக்கூடாது. அதிகாரப்பூர்வ status மற்றும் வரலாறு தான் அந்த மாற்றத்தை நிரூபிக்க வேண்டும். working leg ரத்து, நிராகரிப்பு அல்லது expiry அடைந்தால் pending leg என்ன நிலை எடுத்தது என்பதையும் பட்டியல் பதிலிலிருந்து சரிபார்க்க வேண்டும்.

trigger ஏற்பட்ட பின் pending leg வேலை செய்யத் தகுதி பெற்றாலும் அது விரும்பிய விலையில் fill ஆகிவிட்டது என்று பொருளல்ல. சந்தை அந்நேரத்திற்குள் நகர்ந்திருக்கலாம்; limit order காத்திருக்கலாம்; filter அல்லது மீதத் தொகை நிபந்தனை மாறியிருக்கலாம். ஆகவே OTO-வை இரண்டு கட்ட முடிவாக அல்ல, குறைந்தது நான்கு சான்றுகளாகப் பாருங்கள்: working கோரிக்கை, working fills, pending activation, pending result. முதல் சான்று இல்லாதபோது பின்னையதை கைமுறையாக உருவாக்குவது duplicate exposure ஏற்படுத்தலாம்.

OTO-வில் முக்கியமான கேள்வி working leg எப்போது முழுமையான fill நிலையை அடைந்தது என்பதாகும். பல partial fills இருந்தால் ஒவ்வொரு execution quantity-யின் கூட்டுத்தொகை origQty-க்கு சமமாகும் நேரத்தைக் கண்டுபிடியுங்கள். அதற்கு முன் pending leg தகுதி பெற்றதாக எழுத வேண்டாம். order பதில், user-data நிகழ்வு, வரலாறு query ஆகியவை நேர ஒழுங்கில் வேறுபடலாம்; server timestamp-ஐ முதன்மை reference ஆக வைத்து local receipt time-ஐ துணைத் தகவலாகப் பாதுகாக்கவும். clock drift அதிகமாக இருந்தால் நிகழ்வு order குறித்து certainty குறையும்; அதைப் பதிவு செய்து integration-ஐ நிறுத்த வேண்டும்.

முழு fill நேரத்திற்கு பின் pending leg identifier மற்றும் status மாறியதா என்று பார்க்கவும். activation பதில் கிடைத்தாலும் filter acceptance மற்றும் matching result தனி அடுக்குகள். pending order ஒரு limit என்றால் NEW நிலையில் காத்திருக்கலாம்; marketable order என்றால் fills விரைவாக வரலாம்; rejection இருந்தால் error காரணம் தேவை. எந்த முடிவிலும் first leg fill அளவை second leg fill அளவுடன் நேரடியாகக் கழித்து net நிலைப்பதிவு என்று மட்டும் எழுதாதீர்கள். fees, different prices மற்றும் remaining open quantity சேர்ந்து actual மீதத் தொகை-ஐ மாற்றும்.

நிகழ்வு பதிவு இல்லாமல் OTO automation நடத்துவது support விசாரணையையும் கடினமாக்கும். குறைந்தபட்ச log-ல் list id, working id, pending id, origQty, cumulative executed quantity, activation timestamp, final status மற்றும் query ஆதாரம் இருக்க வேண்டும். sensitive header அல்லது signature log செய்யத் தேவையில்லை. pending leg ஒருபோதும் activation பெறவில்லை என்றால் காரணம் working cancellation, expiry, rejection அல்லது unknown list நிலை ஆக இருக்கலாம். சான்று இல்லாத இடத்தில் platform bug என்று முடிவெடுக்காமல் unresolved என்று வையுங்கள்.

பகுதி நிறைவேற்றம் நிகழ்ந்தவுடன் மீதமுள்ள quantity, கட்டணம் கழிக்கப்பட்ட சொத்து, இன்னும் திறந்திருக்கும் leg, ரத்து கோரிக்கையின் நேரம் ஆகியவற்றை தனித்தனியாகப் பதிவு செய்ய வேண்டும். ஒரு leg-ல் சிறிய fill இருப்பது முழுப் பட்டியலும் முடிந்தது என்று பொருளல்ல. மறுபடியும் ஆர்டர் அனுப்புவதற்கு முன் அதிகாரப்பூர்வ நிலை விசாரணை மற்றும் மீதத் தொகை reconciliation இரண்டும் ஒரே கதையைச் சொல்கிறதா என்று பார்க்க வேண்டும்.

PRICE_FILTER price மற்றும் stopPrice மதிப்புகளின் குறைந்த அளவு, அதிக அளவு, tickSize ஆகியவற்றைச் சரிபார்க்கும். LOT_SIZE quantity-யின் minQty, maxQty, stepSize எல்லையைப் பார்க்கும். MIN_NOTIONAL அல்லது NOTIONAL விலை பெருக்கப்பட்ட அளவின் நிபந்தனைகளை விதிக்கலாம். MAX_NUM_ORDERS, MAX_NUM_ALGO_ORDERS, MAX_NUM_ORDER_LISTS போன்றவை ஏற்கெனவே திறந்துள்ள உத்தரவுகளால் பாதிக்கப்படலாம். ஒரு OTOCO-வின் மூன்று legs-லிருந்து ஏதேனும் ஒரு மதிப்பு தவறாக இருந்தால் முழுப் பட்டியல் எதிர்பார்த்தபடி ஏற்கப்படாமல் போகலாம். பழைய spreadsheet மதிப்பை மறுபயன்படுத்துவது தற்போதைய filter சான்றல்ல.

சோதனையில் முதலில் பயனர் உள்ளிட்ட raw value-ஐ மாற்றாமல் சேமியுங்கள். அதன் அருகில் tickSize அல்லது stepSize-க்கு ஏற்ப கணக்கிட்ட candidate-ஐ எழுதுங்கள். rounding செய்த பின் முதற்கண் நோக்கம் மறைந்து விடக்கூடாது. OCO-க்கு இரு legs விலை உறவைச் சரிபார்க்கவும்; OTO-க்கு activation நேரத்தில் pending order சந்திக்கும் விதிகளை முன்னரே பார்க்கவும்; OTOCO-க்கு மூன்று legs ஒவ்வொன்றையும் சோதித்து பட்டியல் வரம்பை இறுதியில் சேர்க்கவும். இடைமுகம் ஒரு பிழையைத் தடுத்தாலும், அது தனிப்பட்ட risk முடிவை எடுத்துவிட்டதாக எண்ண வேண்டாம்.

பட்டியல் ஏற்கப்படாமல் insufficient மீதத் தொகை வந்தால் portfolio total மட்டும் பார்க்காதீர்கள். ஏற்கெனவே உள்ள limit orders, withdrawals, other lists அல்லது தயாரிப்பு transfers சொத்து-ஐ lock செய்திருக்கலாம். available மீதத் தொகை தான் புதிய order-க்கு தொடர்புடையது. open orders பட்டியலை symbol மட்டுமல்ல சொத்து exposure அடிப்படையிலும் பாருங்கள். quote சொத்து வேறு symbol-ல் lock ஆகலாம். cancel கோரிக்கை அனுப்பியிருந்தாலும் terminal status வரும்வரை amount தொடர்ந்து lock ஆகலாம். இந்த நிலைத் தகவல் இல்லாமல் quantity குறைத்து மீண்டும் முயல்வது காரணத்தைத் தீர்க்காது.

MAX_NUM_ORDER_LISTS மற்றும் மற்ற order-count filters count செய்வது வேறுபடலாம். OTOCO ஒன்று list count-ல் ஒன்று என்றாலும் individual unfilled orders தனி வரம்பை பாதிக்கலாம். கணக்கு-level மற்றும் symbol-level filters இரண்டுமே இருக்கக்கூடும். தற்போதைய exchange information மற்றும் error code இணைத்து காரணத்தைப் புரியுங்கள். எந்த வரம்பை அடைந்தீர்கள் என்பது தெரியாமல் பழைய orders அனைத்தையும் bulk cancel செய்வது தேவையற்ற market exposure மாற்றத்தை உருவாக்கலாம்.

Locked மீதத் தொகை reconciliation-ல் opening available, new locks, fills, fees, cancellations, unlocks, closing available என்ற சமன்பாடு உதவும். ஒவ்வொரு நிகழ்வு-க்கும் timestamp இருக்க வேண்டும். வேறுபாடு இருந்தால் rounding, fee சொத்து, pending settlement அல்லது மறைந்த open order பார்க்கவும். ₹ மதிப்பு rounding-ஐ base quantity வேறுபாட்டை மறைக்க அனுமதிக்காதீர்கள். native units சரியான பின் மட்டுமே INR summary சேர்க்கப்பட வேண்டும்.

OTO-வில் working leg முழுமையாக நிறைவேறியதை எந்தச் சான்று காட்டுகிறது என்பதை முன்கூட்டியே தீர்மானிக்க வேண்டும். UI நிறம், notification அல்லது மீதத் தொகை மாற்றம் ஒன்றே போதாது; order status, executed quantity மற்றும் தொடர்புடைய பட்டியல் நிலையை இணைத்து வாசிக்க வேண்டும். Pending leg இன்னும் உருவாகவில்லை என்றால் அதனை கைமுறையாக நகலெடுப்பதற்கு முன் காரணத்தைப் புரிந்துகொள்ள வேண்டும்.

பத்து unit working leg-ல் நான்கு unit fill, ஆறு unit remaining என்றால் மீதத் தொகை ஏற்கெனவே மாறியிருக்கும்; ஆனால் OTO pending leg இன்னும் வேலை செய்யாமல் இருக்கலாம். அந்நேரத்தில் பத்து unit அளவுக்கு கைமுறை பிந்தைய order சேர்ப்பது அதிகப்படியான exposure உருவாக்கும். executedQty, origQty, list status, pending status, available மீதத் தொகை ஆகிய ஐந்து புலங்களும் பார்க்கப்பட வேண்டும். OCO-வில் ஒரு leg பகுதி fill ஆனபோது மற்ற leg ரத்து நடந்ததா, மீதமுள்ள அளவு என்ன ஆகியவை நிகழ்வு வரலாறு மூலம் தீர்மானிக்கப்பட வேண்டும். card-ல் நிறம் மாறியது அளவு சான்றாகாது.

கணக்குப் பட்டியலில் ஒவ்வொரு fill-க்கும் base quantity, quote value, fee சொத்து, fee quantity, timestamp ஆகியவை இருக்க வேண்டும். average price என்பது fills-லிருந்து மீண்டும் கணக்கிடக்கூடியதாக இருக்கட்டும். ரத்து செய்யப்பட்ட quantity-யை fill quantity-யுடன் சேர்க்காதீர்கள். ஒரே order list-ன் மொத்த நோக்கத்தைப் புரிந்துகொள்வதற்கு ஒவ்வொரு leg நிலை தேவையாக இருந்தாலும், நிதிப் பதிவு individual fills அடிப்படையில் இருக்க வேண்டும். இந்தப் பிரிப்பு வரி மதிப்பாய்விலும் தவறான முழு விற்பனை அல்லது முழு கொள்முதல் பதிவு உருவாகாமல் உதவும்.

cancel பொத்தான் செயல்பட்டது அல்லது API cancel பதில் வந்தது என்பதனால் அதற்கு முந்தைய millisecond-ல் fill இல்லை என்று நிரூபிக்க முடியாது. சந்தை இயந்திரமும் ரத்து கோரிக்கையும் ஒரே நேரத்திற்கு அருகில் செயல்படலாம். cancel பதில், execution reports, trade வரலாறு, open orders மற்றும் மீதத் தொகை ஆகியவற்றை ஒரே timestamp வரிசையில் வையுங்கள். மற்ற leg ரத்து ஆனதாகத் தெரிந்தாலும் அதில் முன்பு பகுதி fill உள்ளதா என்று பார்க்க வேண்டும். ரத்து முடிவு தெரியாதபோது எதிர் order சேர்ப்பது நிலையை மேலும் சிக்கலாக்கும்.

பயனர் செய்ய வேண்டிய பாதுகாப்பான இடைநிலை நடவடிக்கை புதிய உத்தரவுகளை நிறுத்தி சான்று snapshot எடுப்பதாகும். orderListId, orderId-கள், client ids, symbol, side, type, origQty, executedQty மற்றும் non-sensitive price summary போதுமானவை. API secret, signature, OTP அல்லது கணக்கின் முழுத் திரைப் படம் தேவையில்லை. support-க்கு அனுப்பும்போது கோப்பில் பெயர், மின்னஞ்சல், மீதத் தொகை மற்றும் device identifiers மறைக்கப்பட வேண்டும். மூன்று ஆதாரங்களும் ஒரே இறுதி நிலையை காட்டிய பின்பே மீதமுள்ள சொத்தைப் பற்றிய அடுத்த தனிப்பட்ட முடிவை எடுக்கலாம்.

Stop சார்ந்த leg trigger level-ஐ சந்தை வேகமாகத் தாண்டினால் அடுத்த order அதன் வகைக்கு ஏற்ப book-ல் நுழையும். stop-limit என்றால் குறிப்பிடப்பட்ட limit-ல் liquidity இல்லாமல் காத்திருக்கலாம். market execution கிடைக்கும் விலைகளில் நடைபெறலாம்; slippage இருக்கலாம். OCO மற்ற leg-ஐ ரத்து செய்தாலும் triggered leg முழுமையாக fill ஆகும் என்று அதுவே சொல்லாது. OTOCO-வின் pending OCO activation மற்றும் சந்தை gap அருகருகே வந்தால் events வேகமாக மாறலாம்; கண்காணிப்பு interval போதாமல் இருக்கலாம்.

Gap scenario simulation-ல் ஒரு single price line போதாது. activationக்கு முன் price, activation trade, best bid/ask depth, trigger, order submission, partial fills, cancel ஆகியவற்றை வரிசைப்படுத்துங்கள். historical candle high/low மட்டும் exact நிகழ்வு order கொடுக்காது. simulation கல்வி உதவி; live fill prediction அல்ல. நிலையான சந்தை எடுத்துக்காட்டில் வேலை செய்த setup வேகமான சந்தையில் வேறு முடிவு தரலாம்.

Risk budget-ல் worst observed slippage மட்டும் அல்ல, executable liquidity தெரியாத நிலையும் சேர்க்க வேண்டும். இழப்பைச் சமாளிக்க முடியாத quantity என்றால் தொடர்புடைய order automation அதை ஏற்றதாக மாற்றாது. குடும்பத் தேவைக்கான ₹ அளவு அல்லது கடன் தொகை இதில் சேரக்கூடாது. system-ன் நோக்கம் உறவை நிர்வகிப்பது; நிதி திறனை உருவாக்குவது அல்ல.

OTOCO பயிற்சியில் முதல் leg, பிந்தைய OCO-வின் மேல் leg, கீழ் leg ஆகிய மூன்றுக்கும் தனி அடையாளம் மற்றும் நோக்கம் எழுதப்பட வேண்டும். முதல் leg முடிந்தபின் பிந்தைய இரண்டு legs எந்த விலை உறவைப் பயன்படுத்துகின்றன, ஒன்றில் fill ஏற்பட்டால் மற்றொன்று எவ்வாறு முடியும், cancel வந்தால் எந்த exposure மீள்கணக்கிடப்பட வேண்டும் என்பவை ஒரே வரைபடத்தில் இருக்க வேண்டும்.

Spot REST பொதுத் தகவல் timeout ஏற்பட்டால் execution status UNKNOWN ஆக இருக்கலாம் என்று எச்சரிக்கிறது. இதன் பொருள் matching engine வேண்டுகோளை ஏற்கவில்லை என்பதல்ல; client-க்கு இறுதி பதில் நேரத்தில் வரவில்லை என்பதே. அதே OTOCO-வை உடனே மீண்டும் அனுப்பினால் இரண்டு பட்டியல்கள் உருவாகக்கூடும். ஒரே client order identifier, query endpoint, open orders, order-list வரலாறு, fills ஆகியவற்றைப் பயன்படுத்தி முதல் வேண்டுகோள் இருந்ததா என்பதைத் தேட வேண்டும். கண்டுபிடிக்கும் வரை automation retry நிறுத்தப்பட வேண்டும்.

தெரியாத நிலைக்கான runbook முன்கூட்டியே எழுதப்பட வேண்டும். முதலில் உள்ளூர் நேரமும் server நேரமும் பதிவு; அடுத்து கோரிக்கை identifier; பின்னர் query முயற்சிகளின் நேரம் மற்றும் முடிவு; அதன் பின் மீதத் தொகை snapshot. ஒரு குறிப்பிட்ட காலத்திற்குப் பின் கூட முடிவு கிடைக்கவில்லை என்றால் அதிகாரப்பூர்வ support வழியில் குறைந்த தகவலுடன் கேள்வி. retry count-ஐ அதிகரிப்பது விசாரணை அல்ல. network மீண்டதும் முதலில் நிலை reconciliation செய்து, பழைய pending வேலை முடிந்ததா என்று அறிந்த பின்பே புதிய intent அனுமதிக்கப்பட வேண்டும்.

Invalid quantity, price precision, notional அல்லது filter தோல்வி வகைகள் symbol rules-க்கு மீண்டும் செல்லச் சொல்கின்றன. insufficient மீதத் தொகை அல்லது too many orders என்பது available மீதத் தொகை, locked amount, open-order count ஆகியவற்றைத் தேவைப்படுத்தும். timestamp, signature, அனுமதி பிழைகள் credential மற்றும் clock கட்டுப்பாட்டை நிறுத்திச் சரிபார்க்கச் சொல்கின்றன. unknown order அல்லது list status முரண்பாடு identifiers மற்றும் வரலாறு-ஐ ஆய்வு செய்ய வேண்டும். ஒரே error message-க்கு பல காரணங்கள் இருக்கலாம்; முழு code மற்றும் message சேமிக்காமல் பொதுவாக system error என்று எழுதுவது உதவாது.

பிராந்திய அல்லது தயாரிப்பு கிடைப்புப் பிழை வேறு வகை. கணக்கில் வசதி காட்டப்படவில்லை என்றால் VPN, வேறு நபரின் கணக்கு, தவறான அடையாளத் தகவல் அல்லது அனுமதியற்ற மூன்றாம் தரப்பு வழி பயன்படுத்தக்கூடாது. அதிகாரப்பூர்வ அறிவிப்பு மற்றும் கணக்கு ஆதரவைப் பார்த்து unavailable என்று பதிவு செய்யுங்கள். விதியை மீறி அணுகுவது order-list தொழில்நுட்பப் பிரச்சினையைத் தீர்ப்பதில்லை; கணக்கு மற்றும் சட்ட ஆபத்தை அதிகரிக்கலாம்.

தனிப்பட்ட client identifier மனிதர் வாசிக்கத் தக்க குறுகிய structure கொண்டிருக்கலாம்: system code, date fragment, intent sequence, leg role போன்றவை. அதில் email, phone, PAN, கணக்கு number அல்லது strategy secret எழுதக்கூடாது. list-level identifier மற்றும் leg-level identifiers தனித்தன்மை பெற வேண்டும். retry முயற்சி வந்தால் அதே intent-க்கு புதிய id உருவாக்குவதற்கு முன் பழைய id query செய்யப்பட வேண்டும். identifier வெறும் label அல்ல; timeout மற்றும் duplicate reconciliation-க்கு தேடல் விசை.

அடையாளத்தின் ஆயுள் cycle பதிவு செய்யுங்கள். generated, submitted, acknowledged, queried, terminal என்று நிலைகளை வைத்தால் அனுப்பப்படாத வரைவை live order என்று தவறாகப் புரியாது. OTO pending leg id கோரிக்கை நேரத்திலேயே கிடைத்தாலும் activation நேரம் வேறு. OTOCO-வில் மூன்று ids மற்றும் ஒரு list id இடையேயான mapping immutable ஆக இருக்க வேண்டும். database update பழைய id-ஐ overwrite செய்தால் audit chain முறியும். append-only நிகழ்வு வரலாறு அல்லது versioned பதிவு சிறந்தது.

Manual இடைமுகம் client id காட்டாத சூழலில் platform வழங்கும் order ids மற்றும் export வரலாறு-ஐப் பயன்படுத்துங்கள். screenshot file name-ஐ ஒரே identifier ஆகக் கொள்ள வேண்டாம்; அது மாற்றப்படலாம். support case number கிடைத்தால் order identifier-க்கு மாற்றாக அல்ல, தொடர்புடைய reference ஆகச் சேர்க்கவும். ஒரே id வேறு symbol-ல் தோன்றுகிறது என்றால் கணக்கு, environment மற்றும் data ஆதாரம் சரியா என்று நிறுத்திச் சரிபார்க்க வேண்டும்.

இந்திய INR பதிவு சந்தை முடிவை மாற்றும் signal அல்ல. ஒவ்வொரு fill-ன் native சொத்து அளவு, fee சொத்து, நேரம் மற்றும் transaction identifier முதலில் பாதுகாக்கப்பட வேண்டும்; பின்னர் தேர்ந்தெடுத்த மாற்று விகித ஆதாரம் மற்றும் நேரத்தைச் சேர்த்து INR வேலைப்பதிவு செய்யலாம். வரி அல்லது AML விளக்கம் தனிப்பட்ட முடிவாகக் கொள்ளப்படாது; தற்போதைய அதிகாரப்பூர்வ உரையும் தகுதியான ஆலோசனையும் தேவை.

முதல் சோதனை list id மற்றும் ஒவ்வொரு order id கிடைத்ததா. இரண்டாவது list status மற்றும் individual status முரண்படுகிறதா. மூன்றாவது executedQty மொத்தம் trade வரலாறு-யுடன் பொருந்துகிறதா. நான்காவது fee கழித்த மீதத் தொகை மாற்றம் விளக்கமளிக்கிறதா. ஐந்தாவது ரத்து செய்யப்பட வேண்டிய leg இன்னும் open ஆக உள்ளதா. ஆறாவது OTO அல்லது OTOCO pending leg உண்மையில் activation பெற்றதா. ஏழாவது timeout இருந்தால் duplicate list தோன்றியுள்ளதா. இந்த ஏழு கோணங்களும் ஒரே கதையைச் சொன்னால் மட்டுமே operation reconciled என்று குறிக்கவும்.

ஒரு முரண்பாடு இருந்தால் அதை புதிய order மூலம் மறைக்காதீர்கள். எடுத்துக்காட்டாக list page ALL_DONE என்றாலும் ஒரு leg open orders-ல் தெரிந்தால் நேரம், cache, symbol மற்றும் கணக்கு சரியா என்று பார்க்க வேண்டும். fill வரலாறு இருக்கும்போது மீதத் தொகை மாறவில்லை என்றால் fee சொத்து, locked மீதத் தொகை அல்லது வேறு open order-ஐச் சரிபார்க்கவும். சான்று table-ல் unresolved என்ற நிலை இருக்க வேண்டும்; forced completed value வேண்டியதில்லை. இந்த நேர்மை அடுத்த ஆய்வாளர் பிழையான முன்னெண்ணத்தில் தொடங்குவதைத் தடுக்கிறது.

ஒரு fill-ன் fee base சொத்து-ல், quote சொத்து-ல் அல்லது வேறு தகுதியான சொத்து-ல் வசூலிக்கப்படலாம். அதனால் executedQty முழுவதும் கிடைக்க வேண்டிய மீதத் தொகை என்று நேரடியாகக் கணக்கிட்டால் வேறுபாடு வரும். ஒவ்வொரு trade பதிவு-ன் commission சொத்து மற்றும் amount பாதுகாக்கப்பட வேண்டும். OTO working fill பிறகு pending quantity வடிவமைக்கப்பட்டிருந்தால் fee காரணமாக available base amount சிறிது குறையலாம்; தயாரிப்பு rule தானாக என்ன செய்கிறது என்பதை பதில் மூலம் மட்டுமே அறிய வேண்டும். ஊகித்து quantity மாற்ற வேண்டாம்.

Decimal precision இரண்டு இடங்களில் தாக்கம் செய்கிறது: order input stepSize மற்றும் accounting காட்சி rounding. UI ஆறு decimals மட்டும் காட்டினாலும் export அதிக precision கொண்டிருக்கலாம். reconciliation அதிக precision தரவைப் பயன்படுத்தி, report-ல் rounding policy வெளிப்படையாக இருக்க வேண்டும். சிறிய dust amount-ஐ zero என்று நீக்கினால் மாதாந்திர சொத்து total ஒப்பாது. INR conversion-ல் கூடுதல் rounding சேரும் என்பதால் native quantity முதன்மை.

பல legs fills பெற்றால் weighted average price ஒவ்வொரு fill price மற்றும் quantity மூலம் கணக்கிடப்பட வேண்டும். canceled quantity denominator-ல் வரக்கூடாது. fee கழித்த net சொத்து மற்றும் gross executed quantity இரண்டையும் வைத்திருங்கள். இதனால் trading result பற்றி தீர்ப்பு அளிக்காமல் order mechanics சரியாகப் பதிவானதா என்று பார்க்கலாம்.

வாராந்திர audit-ல் ஒவ்வொரு பட்டியலுக்கும் உருவாக்கம், activation, fill, cancel, reject மற்றும் இறுதி மீதத் தொகை ஆகிய ஆறு வகைச் சான்றுகளில் பொருந்துபவை இணைக்கப்பட வேண்டும். எந்த leg-க்கும் விளக்கமில்லாத மாற்றம் இருந்தால் அந்தப் பட்டியல் முடிந்ததாகக் குறிக்கக் கூடாது. இவ்வாறு திறந்த கேள்வியைத் தெளிவாக வைத்திருப்பது பொய்யான முழுமையைவிட பாதுகாப்பானது.

வரைகலை முகப்பில் பட்டியல் பெயர் சுருக்கமாக இருக்கலாம்; API ஆவணம் working order, pending order, list identifiers, status enums போன்ற உறவுகளை வெளிப்படையாகத் தருகிறது. அதனால் எந்தப் பொத்தானை அழுத்த வேண்டும் என்று கற்றுக்கொள்வதற்காக அல்ல, தயாரிப்பு semantics-ஐச் சரிபார்ப்பதற்காக இந்த ஆதாரங்கள் பயன்படுத்தப்படுகின்றன. சாதாரண வாசகர் API key உருவாக்க வேண்டியதில்லை. document எடுத்துக்காட்டில் உள்ள parameter-ஐ கணக்கு-க்கு நகலெடுப்பதும் தேவையில்லை. ஆவணம் விதி வரைபடம்; தனிப்பட்ட இடைமுகம் மற்றும் அனுமதி தனி சான்று.

ஒரு developer உண்மையில் integration அமைத்தால் trade-only குறைந்த அனுமதி, IP restriction, secret manager, server-time sync, rate limits, masked logs ஆகியவை அடிப்படை. withdrawal அனுமதி திறக்கக்கூடாது. client order ids மீளாதவையாக இருக்க வேண்டும்; timeout query path எழுதப்பட வேண்டும்; production-க்கு முன் குறைந்த தாக்கம் கொண்ட verification தேவை. secret அல்லது signature log-ல் வந்தால் அந்த key-ஐ உடனே revoke செய்து incident மதிப்பாய்வு செய்ய வேண்டும். automation உயர்ந்தால் reconciliation பொறுப்பு குறையாது; மனிதன் பார்க்கும் சான்று மேலும் தெளிவாக வேண்டும்.

Trade endpoint-ல் புதிய list type, parameter அல்லது பதில் புலம் வந்தால் OCO சொல் இருக்கிறது என்பதற்காக பழைய நிலை diagram-க்கு சேர்க்காதீர்கள். list creation, leg eligibility, trigger, cancellation, partial fill, timeout, error, filter counting ஆகிய எட்டு பொருட்களையும் மறுசோதியுங்கள். Enums பக்கத்தில் புதிய status வந்தால் local parser unknown value-ஐ பாதுகாப்பாகக் கையாள வேண்டும். Filters பக்கம் மாறினால் stored constants நீக்கப்பட்டு live query சான்று பெறப்பட வேண்டும். மாற்றம் பதிவு செய்யப்படும் வரை automation write பாதை நிறுத்தப்படட்டும்.

மதிப்பாய்வு பதிவில் ஆதாரம் URL, access date, changed paragraph, affected test, reviewer ஆகியவை இருக்க வேண்டும். மொழிபெயர்ப்பு பெயர் மட்டும் மாறி semantics மாறவில்லை என்றால் glossary update போதலாம்; activation அல்லது count விதி மாறினால் நிலை tests மீண்டும் ஓட வேண்டும். 2026-08-09 checkedAt பழைய கட்டுரையை புதிய உண்மை என்று காட்ட அனுமதிக்காது. வாசகர் செயல் நாளில் official document மற்றும் கணக்கு notice இரண்டையும் பார்க்க வேண்டும்.

ஒரு order-list ஆய்வு முடிந்தது என்று சொல்ல ஏழு முடிவுகள் தேவை: intent மற்றும் list type பொருந்தியது; filters அன்றையவை; கோரிக்கை தனித்த identifier கொண்டது; working மற்றும் pending eligibility புரிந்தது; fills மற்றும் cancels நேரத்துடன் சேமிக்கப்பட்டது; open orders மற்றும் மீதத் தொகை ஒப்பானது; credentials பாதுகாப்பாக இருந்தது. இதில் ஏதேனும் ஒன்று இல்லை என்றால் unresolved என்று எழுதுங்கள். அந்த label செயல்முறை குறை அல்ல; புதிய செயல் பழைய uncertainty-ஐ மூடாமல் வைத்திருக்கும் பாதுகாப்பு.

OCO, OTO, OTOCO வழங்குவது முன்பே வரையறுக்கப்பட்ட order உறவு. அது சந்தையை கணிக்காது, சரியான quantity-யைத் தேர்வு செய்யாது, கணக்கு availability-ஐ உருவாக்காது, இந்திய compliance அல்லது வரியை முடிவு செய்யாது. வாசகர் அறிய வேண்டிய இறுதி கேள்வி: அடுத்த நிகழ்வு நடந்தால் எந்த leg தகுதி பெறும், எந்த சான்று பார்க்கப்படும், எந்த நிலையில் புதிய உத்தரவு நிறுத்தப்படும்? அந்த மூன்று பதில்களும் தெளிவாக இருந்தால் automation புரிந்ததாகக் கொள்ளலாம்; இல்லையெனில் எளிய single-order கல்விக்குத் திரும்புவது பாதுகாப்பானது.

Support கோரிக்கை-ல் கணக்கு password, OTP, API secret, signature, seed phrase எதுவும் சேரக்கூடாது. தேவையானவை பொதுவாக UTC அல்லது timezone உடன் timestamp, symbol, list type, orderListId, மறைக்கப்பட்ட client id, individual order ids, non-sensitive parameter summary, exact error code, expected நிலை மற்றும் observed நிலை. screenshot இருந்தால் personal fields மறைக்கப்பட வேண்டும். கோரிக்கை ஒரு கேள்வியை மட்டும் தெளிவாகக் கேட்கட்டும்: உதாரணமாக pending leg activation ஏன் வரலாறு-ல் இல்லையென விளக்கம்.

Support பதில் கிடைத்ததும் அது எந்த identifier மற்றும் நேரத்தைப் பற்றியது என்று இணைக்கவும். generic answer-ஐ குறிப்பிட்ட order முடிவு என்று மாற்றாதீர்கள். பதில் கணக்கு action கேட்கிறதா, documentation link தருகிறதா, engineering investigation நடக்கிறதா என்று வகைப்படுத்துங்கள். official domain அல்லது in-app case வழியே மட்டுமே தொடருங்கள். social media direct message-ல் remote access கேட்பவர் அதிகாரப்பூர்வம் என்று பெயர் வைத்திருந்தாலும் நிறுத்துங்கள்.

Case முடிந்த பின் incident note எழுதுங்கள்: முதற்கண் அறிகுறி, root cause தெரிந்ததா, சொத்து exposure, duplicate இருந்ததா, credentials பாதுகாப்பாக இருந்ததா, process change என்ன. காரணம் தெரியவில்லை என்றால் unknown என்று நேர்மையாக வையுங்கள். புதிய automation enable செய்வதற்கு முன் அந்த unknown மீண்டும் வரும்போது safe stop செயல்படுகிறதா என்று test செய்ய வேண்டும்.

ஒரு completed அல்லது unresolved order-list case-க்கு raw order export, trade export, மீதத் தொகை snapshot, filter snapshot, ஆதாரம்-link பட்டியல், நிகழ்வு timeline, masked screenshots, support references மற்றும் reviewer note ஆகியவை ஒரே manifest கீழ் இருக்க வேண்டும். ஒவ்வொரு கோப்புக்கும் உருவாக்கப்பட்ட நேரம், timezone, ஆதாரம் மற்றும் checksum வைத்தால் பின்னர் accidental edit கண்டுபிடிக்கலாம். API பதில் JSON சேமிக்கும்போது headers, signature மற்றும் credential fields நீக்கப்பட வேண்டும். spreadsheet summary raw கோப்புகள்-ஐ மாற்றாது; அது அவற்றின் index மட்டுமே.

Retention காலம் தனிப்பட்ட சட்ட மற்றும் accounting தேவைக்கு ஏற்ப தீர்மானிக்கப்பட வேண்டும். தேவையில்லாத identity data சேர்த்து வைத்திருப்பது பாதுகாப்பை அதிகரிக்காது. order identifiers மற்றும் சொத்து events ஆய்வுக்கு போதுமானபோது email, phone, device id ஆகியவற்றை வேறு பாதுகாக்கப்பட்ட இடத்தில் அல்லது முற்றிலும் நீக்கலாம். cloud link share செய்ய வேண்டியிருந்தால் access expiry மற்றும் named recipients பயன்படுத்துங்கள்; public link வேண்டாம். reviewer வேலை முடிந்த பின் அணுகல் திரும்பப் பெறப்பட வேண்டும்.

காப்பகம் manifest-ன் இறுதி வரி outcome prediction ஆக இருக்கக்கூடாது. list type, final known நிலை, unresolved fields, மீதத் தொகை reconciliation status, ஆதாரம் checked date மற்றும் next மதிப்பாய்வு trigger மட்டும் போதும். புதிய Binance documentation change, கணக்கு dispute, tax மதிப்பாய்வு அல்லது security incident வந்தால் காப்பகம் மீண்டும் திறக்கப்படும். இவ்வாறு சான்று-ஐ ஒழுங்குபடுத்தினால் OCO, OTO, OTOCO automation வேகம் வரலாற்றின் தெளிவை அழிக்காது.

மற்றொரு பொறுப்பாளர் காப்பகத்தைப் பெறும் நாளில் live கணக்கைத் தொடாமல் முதலில் offline reconstruction செய்ய வேண்டும். Manifest-ல் உள்ள list identifier மூலம் working leg மற்றும் pending legs-ஐ இணைத்து, ஒவ்வொரு status மாற்றத்திற்கும் நேரமிட்ட order response அல்லது fill பதிவு உள்ளதா என்று குறிக்க வேண்டும். ஒரு status-க்கு ஆதாரம் இல்லாவிட்டால் ஊகத்தை உண்மையாக எழுதாமல் unresolved என்று வைத்திருக்க வேண்டும். அடுத்ததாக filter snapshot-ன் tick size, step size மற்றும் order-list limit அந்த சமர்ப்பிப்பு நேரத்துக்குப் பொருந்தியதா என்று பார்க்க வேண்டும். அதன் பிறகு quantities, fees மற்றும் இறுதி மீதத் தொகை கணக்கு சமன்பாட்டுடன் பொருந்துகிறதா எனச் சோதிக்கலாம். இந்த வரிசை முடிந்த பின்பே support பதில் அல்லது screenshot கூடுதல் விளக்கமாக சேர்க்கப்படும்; அவை server பதிவை மாற்றாது. இவ்வாறு சுயாதீனமாக மீளுருவாக்க முடியாத பொதி முழுமையான audit சான்று அல்ல. மறுபரிசீலனையைச் செய்தவரின் பெயர், நேரம், கண்ட முரண்பாடு மற்றும் அடுத்த நடவடிக்கையும் தனி பதிவாக இருக்க வேண்டும். அந்தப் பதிவு பழைய முடிவை அழிக்காமல் புதிய அடுக்காக சேர்க்கப்பட வேண்டும்; இதனால் யார் எந்தச் சான்றின் அடிப்படையில் நிலையை மாற்றினார் என்பதை பின்னர் கண்டறிய முடியும். காப்பகத்தை மூடும் முன் unresolved பட்டியல் வெறுமையா, அல்லது ஒவ்வொரு திறந்த கேள்விக்கும் தெளிவான பொறுப்பாளரும் மறுசோதனைத் தேதியும் உள்ளதா என்று இறுதியாகச் சரிபார்க்க வேண்டும். இரண்டிலும் ஒன்று இல்லாவிட்டால் case முடிந்ததாகக் குறிக்க முடியாது.