TT の流量上限と再接続── REST の利用プランと FIX の自動回復を前提に設計する
TT REST API の上限はアプリケーションキーごとの利用プランで決まり、FIX のセッションは週に 1 度リセットされ、再接続すると未送信の約定が自動で届きます。公開資料の数値と動作をもとに、発注・照会の処理をどう組むかを整理します。
インフラAPI
タグ「API」が付与された記事の一覧です。
全15件
インフラ
インフラJ-GATE で注文が止まる仕組み── ハードブロック・NCP・OTR・即時約定可能値幅を発注処理に組み込む
J-GATE には、注文を拒否する、取消を受け付けない、注文の出し方を月次で判定する、取引を一時中断する、という複数の仕組みがあります。それぞれを発注処理のどこで扱うかを整理します。
インフラLSEG Data Library の接続と認証── App Key・Machine ID・サービスアカウントの使い分け
Workspace 経由・クラウド直結・社内配信基盤のどれで接続するかで、必要な資格情報は変わります。App Key と ID の役割、認証方式 V1 と V2 の違い、同じ ID を 2 か所で使うと切れる問題を整理します。
インフラFIX 接続の流量制限と再接続── 切断のあとに注文を二重に出さない設計
流量の上限、切断時の自動取消、再接続での番号の合わせ方、重複の見分け方は、FIX の規格ではなく対向ごとの仕様で決まります。公開仕様を例に、設計で先に決めることを整理します。
ブロックチェーンHyperliquid API の接続と認証── API ウォレットと nonce で発注の権限を設計する
API キーの代わりに、出金できない署名専用の鍵を発注プロセスごとに割り当てます。鍵の分け方と nonce の扱いを最初に決めておけば、本番で原因の分からない拒否に悩まされません。
ブロックチェーン取引所ごとに「同じ意味の値」の名前も型も違う── 正規化レイヤに何を持たせるか
価格も数量も時刻も、取引所ごとに名前と型と単位が揃っていません。bitFlyer と Binance の実際のフィールドを並べて、正規化レイヤの設計を具体的に決めます。
ブロックチェーンDEX への接続は読み取りと送信を分けて設計する── API・SDK・コントラクト直叩きの選び分け
分散型取引所の統合は 3 通りあり、選び方を誤ると作り直しになります。読み取り経路と送信経路を分けて、どこで何を決めるべきかを整理します。
ブロックチェーン暗号資産取引所 API は署名とレート制限で分かれる── 取引所を増やしても壊れない構成にする
REST と WebSocket という形は各社共通でも、署名の作り方とレート制限の数え方は揃っていません。差異をどこに閉じ込めるかを、bitFlyer と Binance の実装で具体的に見ます。
インフラJ-GATE への接続は API と OUCH の選択から始まる── 発注と相場情報を分けて設計する
大阪取引所のデリバティブ売買システムは、発注と相場情報でそれぞれ 2 通りの接続方式を持ちます。組み合わせの決め方と、遅延がどこで生まれるかを整理します。
ブロックチェーンHyperliquid API のレート制限を先に設計する── 取引量が発注枠を決める仕組み
IP 単位の重み付けと、アドレス単位の「取引量に応じた発注枠」の二重構造です。数字を把握してから設計しないと本番で詰まります。
フィンテックオープンバンキングの「次」を読む──PSD3と日本のAPI戦略
欧州ですでに施行済みの義務と、まだ確定していない部分を切り分け、日本の実装で何を準備すべきかを整理します。
インフラBloomberg API（BLPAPI）接続の設計── Desktop・Server・B-PIPE をどう選ぶか
同じコードが動くのに、配信形態を誤ると本番で行き詰まります。3つの提供形態の違いと、接続・認証・バージョン合わせの実務をまとめます。
インフラTrading Technologies（TT）REST API の組み立て方── サービスが分かれている前提で設計する
TT の REST API は用途ごとにサービスが分かれています。どれを組み合わせるか、認証と環境をどう分けるかを整理します。
インフラFIX 接続はセッション層で決まる── シーケンス番号と再送をどう扱うか
注文の項目より先に、セッション層の作りが接続の成否を決めます。シーケンス番号・再送・接続検証で実際に問題になる箇所を整理します。
フィンテック決済ネットワーク連携の最前線── 銀行×フィンテックの共創で何が変わるか
決済の中枢は銀行、利用者接点は事業者。この分担が機能するかは、間をつなぐインターフェースの設計品質に左右されます。