Aracı Kurumlar ve Fintech'ler İçin İşlem ve Nakit Mutabakatı: Ürün Satın Alın, Back Office Modülünüzü Kullanın ya da Kendiniz Geliştirin

Mutabakat, işlem, pozisyon ve nakit kayıtlarınızın dış tarafların kayıtlarıyla örtüştüğünü doğrulayan, genellikle günlük yapılan düzenli kontroldür. Bu dış taraflar, parayı tutan ya da hareket ettiren bankalar, saklama kuruluşları, likidite sağlayıcıları, ödeme sağlayıcıları ve borsalardır. Bir aracı kurum, kripto borsası ya da fintech bir mutabakat ürünü satın alabilir, zaten kullandığı back office'in ya da platformun modülünü kullanabilir ya da kendi eşleştirme ve fark yönetimi iş akışını geliştirebilir. Birden çok karşı tarafı olan ve müşteri parası kurallarına tabi çoğu firma için sağlam cevap, ürünü satın almak, ham verinin kendi kopyanızı tutmak ve yalnızca ürünün yapamadığı kontrolleri geliştirmektir.

Bir mutabakat neleri eşleştirmelidir?

Her kontrol, kayıtlarınızdan birini bir dış kayıtla karşılaştırır. İşin büyük kısmını beş kontrol karşılar:

• İşlemler: platformunuzdaki her gerçekleşme, borsanın, takas aracı kurumunun ya da likidite sağlayıcısının (işlemlerinizin karşı tarafındaki banka ya da aracı kurum) raporuyla karşılaştırılır.
• Pozisyonlar: defterlerinizdeki varlıklar, saklama kuruluşunun ya da likidite sağlayıcısının ekstresiyle karşılaştırılır. Kripto borsasında ise müşteri defteri, blockchain üzerindeki cüzdan bakiyeleriyle karşılaştırılır.
• Nakit: bakiyeler, banka ekstreleriyle ve ödeme hizmeti sağlayıcılarının (PSP) takas raporlarıyla para birimi bazında karşılaştırılır.
• Ücretler ve komisyonlar: sisteminizdeki ücretler, işlem yerlerinden, bankalardan ve PSP'lerden gelen faturalarla karşılaştırılır; yönlendirme ortaklarına ya da bir prop trading firmasında fonlanmış hesabı olan trader'lara borçlu olduğunuz tutarlar da kontrol edilir.
• Müşteri parası: müşteriler için tutmanız gereken tutar, ayrı tutulan hesaplarda ya da fon koruma hesaplarında duran tutarla karşılaştırılır. Aşağıda alıntılanan kuralların çoğu bu kontrolle ilgilidir.

Kontroller ayrıca iki düzeyde yapılır. Bakiye kontrolü belirli bir andaki toplamları karşılaştırır; satır eşleştirme ise bir müşterinin yatırdığı para ile bunun banka kaydı gibi tek tek kalemleri eşler. Defter (ledger) yazılımı satan Formance, kendi mutabakatı için şöyle diyor: “Belirli bir andaki toplam finansal durumu varlık bazında kontrol eder. Tek tek Ledger kayıtlarını banka ya da PSP ekstre satırlarıyla eşleştirmez.” Bakiye kontrolü bir fark olduğunu gösterir. Satır eşleştirme ise farka hangi kalemin yol açtığını gösterir; çoğu firmanın ikisine de ihtiyacı vardır.

Elektronik tablolar ve betikler mutabakatta neden bir noktada yetersiz kalır?

Birçok firma işe bir elektronik tabloyla ya da bir analistin yazdığı bir betikle başlar. Bu yöntem düşük hacimde işler ve öngörülebilir noktalarda aksar:

• Hacim: kısmi gerçekleşmeler, toplu ödemeler ve ücret satırları yüzünden satır sayısı, müşteri sayınızdan daha hızlı artar.
• Formatlar: bir mutabakat sağlayıcısı olan Duco, tipik bir durumu şöyle anlatıyor: “bir dosya para birimini bir sembolle, diğeri üç harfli kodla gösteriyor, tarihler birden fazla formatta ve çoğu zaman bazı veriler eksik.” Tek bir dosya düzenine göre yazılmış bir betik, bir sütunun yeri değiştiğinde sessizce bozulabilir.
• Zamanlama: ekstreler farklı kesim saatlerinde ve farklı saat dilimlerinde gelir; bu yüzden bir elektronik tablo, geç gelen bir ekstreyi eksik bir ödemeden ayırt edemez.
• Yaşlandırma ve denetim izi: bir elektronik tablo, bir farkın ne kadar süredir açık olduğunu ya da iki satırı kimin, neden eşleştirdiğini nadiren gösterir.

Bu sorun büyük firmalarda da var. Mutabakat yazılımı satan Gresham şöyle yazıyor: “Finansal hizmetlerde neredeyse her kurumsal mutabakat platformunun yanında bir yığın elektronik tablo mutabakatı durur.” Bu tablolardan birini platforma taşımak “çoğu zaman uzman kaynakları, sağlayıcıyla çalışma, devreye alma çalışmaları ve değişiklik yönetimi açısından, onu olduğu yerde bırakmaktan daha pahalıya gelir.”

Düzenleyiciler müşteri parası ve fon koruma mutabakatlarından ne bekliyor?

Kurallar ülkeye ve lisansa göre değişir; bu alıntılar da her rejimin tamamı değildir. Onları avukatınız için bir harita olarak kullanın.

• Birleşik Krallık'taki ödeme ve elektronik para kuruluşları. Finansal Davranış Otoritesi (FCA), PS25/12 sayılı politika bildirimiyle CASS 15 bölümünü ekledi ve kuralların 7 Mayıs 2026'da yürürlüğe gireceğini açıkladı. İç ve dış mutabakatlar “gerektiği sıklıkta ve her mutabakat gününde en az bir kez” yapılmalıdır. Hafta sonları, resmî tatiller ve ilgili bir yabancı piyasanın kapalı olduğu günler mutabakat günü sayılmaz. Eksik tutar “mümkün olan en kısa sürede ve her durumda mutabakatın yapıldığı günün sonuna kadar” yatırılmalıdır.
• Birleşik Krallık'taki yatırım kuruluşları. FCA, müşteri parasına ilişkin 2014 tarihli nihai kurallarında (PS14/9, CASS 7 bölümü) “her iş günü” iç mutabakat yapılmasını şart koştu. Mutabakatın “firmanın bir önceki iş gününün kapanışı itibarıyla kayıtlarına dayanması” gerekiyordu. Dış mutabakatlar, aralarında “gerektiği kadar düzenli, ancak bir aydan fazla süre geçmesine izin vermeden” yapılmalıydı. FCA'nın kılavuzu, her gün işlem yapan firmaların çoğu durumda “her iş günü bir dış müşteri parası mutabakatı yapması gerektiğini” söylüyordu. FCA 2026'da bu kuralları içeren CASS 7.15 kısmını değiştirdi; bu yüzden El Kitabı'ndaki güncel metni kontrol edin.
• AB yatırım kuruluşları. Kabul edildiği haliyle aktarılan (AB) 2017/593 sayılı Komisyon Delege Direktifi'ne göre firmalar “iç hesap ve kayıtları ile bu varlıkları elinde tutan üçüncü tarafların hesap ve kayıtları arasında düzenli olarak mutabakat yapmalıdır”. Direktif, üye devletlerden bunu zorunlu kılmalarını istiyor; bu yüzden ulusal kurallarınızı kontrol edin.
• AB ödeme kuruluşları. Kabul edildiği haliyle aktarılan (AB) 2015/2366 sayılı Ödeme Hizmetleri Direktifi'nin 10. maddesi, müşteri fonlarının nasıl korunacağını belirliyor; örneğin “bir kredi kuruluşundaki ayrı bir hesapta”. Madde mutabakattan söz etmiyor. Düzenleyicinize hangi kanıtı beklediğini sorun.
• AB kripto varlık hizmet sağlayıcıları. Kripto Varlık Piyasaları Tüzüğü (MiCA) burada, AB menkul kıymetler düzenleyicisi ESMA'nın çevrimiçi kural kitabından aktarılıyor. Tüzüğün 75. maddesine göre saklama kuruluşu “her müşteri adına açılmış bir pozisyon sicili” tutar. Bu sicile “bir müşterinin haklarını doğurması ya da değiştirmesi muhtemel her olay derhal kaydedilir”. Sicilin blockchain üzerindeki cüzdan bakiyeleriyle mutabakatı, ikisinin örtüşüp örtüşmediğini gösterir.
• ABD aracı kurumları. Menkul Kıymetler ve Borsa Komisyonu'nun (SEC) Rule 15c3-3 düzenlemesine göre, müşteri fonlarını ya da menkul kıymetlerini tutan bir aracı kurum defterlerini “en geç bir sonraki iş günü” kontrol eder. Bunu, tamamı ödenmiş ve fazla teminat (excess margin) niteliğindeki menkul kıymetlerden ne kadarının zilyetliğinde ya da kontrolünde olduğunu, ne kadarının olmadığını belirlemek için yapar. Çoğu durumda müşteri rezervini haftalık olarak hesaplar; ortalama toplam alacakları 500 milyon dolara ulaşırsa en geç altı ay sonra günlük hesaplamaya geçer. Rule 17a-13, menkul kıymetlerin, saklanmalarından ve kayıtlarından bağımsız kişilerce üç ayda bir sayılmasını ve karşılaştırılmasını şart koşar. Çözülmemiş farklar sayımdan sonra “en geç 7 iş günü içinde” deftere işlenir.

Her mutabakat için tarihli bir kayıt da gerekir. Örneğin CASS 15, firmanın “ilgili süreci yürüttüğü saati ve tarihi” ve “attığı adımları” kaydetmesini ve kayıtlarını 5 yıl saklamasını istiyor.

Her karşı taraftan gelen veriyi tek bir formata nasıl getirirsiniz?

Herhangi bir şey eşleştirilmeden önce dosyaların ve mesajların zamanında ve tek bir formatta gelmesi gerekir. Gresham, “SWIFT mesajları, FIX feed'leri, ISO 20022 ödeme mesajları, saklama kuruluşu dosyaları, prime broker feed'leri” gibi kaynakları sayıyor. SWIFT ve ISO 20022 banka mesaj standartlarıdır; FIX ise alım satım işlemlerinde kullanılan bir mesaj formatıdır. Zamanlama da kaynağa göre değişir. Aracı kurumlara B2CORE back office'ini satan B2Broker bir örnek veriyor. Trading platformu bir gerçekleşme gösteriyor, ama “likidite sağlayıcısı farklı bir miktarı onaylıyor ve bir kripto cüzdanı fonlamayı bir saat sonra kaydediyor.”

Normalizasyon bu kaynakları karşılaştırılabilir hale getirir:

• Tanımlayıcılar: enstrüman kodlarınızı, hesaplarınızı ve işlem kimliklerinizi her karşı tarafın kullandıklarıyla eşleyin.
• Tutarlar: tek bir işaret kuralı, tek bir para birimi kodu ve yeterli ondalık basamak. Gresham, kripto varlıkların “18 ondalık basamağa kadar” içerebildiğini belirtiyor.
• Zaman: tek bir saat dilimi ve her kaynak için sabit bir kesim saati. FCA'nın fon koruma kuralları, mutabakat noktalarının “her gün aynı saat(ler)de” olmasını şart koşuyor.
• Mükerrer kayıtlar ve boşluklar: iki kez gönderilmiş bir dosya ya da eksik bir gün.

Her dosyayı, normalize edilmiş kopyasının yanında, tam olarak geldiği haliyle saklayın. Bir karşı taraf bir farka itiraz ettiğinde ham dosya sizin kanıtınızdır; ayrıca bir kural değiştikten sonra eşleştirmeyi yeniden çalıştırmanızı sağlar.

Eşleştirme kuralları ve toleranslar nasıl işlemeli?

Eşleştirme kuralı, iki kaydın tek bir kalem sayılması için hangi alanların örtüşmesi gerektiğini belirler. İşlemlerde bunlar genellikle işlem ya da emir kimliği, enstrüman, yön, miktar ve fiyattır. Nakitte ise genellikle tutar, para birimi, valör tarihi ve referanstır. Eşleşmeler bire bir olabilir; örneğin bir gerçekleşme ile likidite sağlayıcısının işlem fişi. Bire çok olabilir; örneğin bir PSP'nin toplu ödemesine karşılık gelen tek bir banka alacak kaydı. Ya da çoka çok olabilir; örneğin iki taraftaki kısmi gerçekleşmelerin emir toplamları üzerinden eşleştirilmesi.

Tolerans, eşleşme olarak kabul ettiğiniz farktır; örneğin bir döviz çevriminden sonra kalan yuvarlama farkı. Duco, “kullanıcının belirlediği toleransları, toplulaştırma kurallarını, bulanık eşleştirmeyi ve çok geçişli işlemeyi” gerçek olmayan farkları ortadan kaldırmanın yolları olarak anlatıyor. Gresham, “N yönlü mutabakatlar, tek bir çalıştırmada üç ya da daha fazla veri kaynağı arasında eşleştirme” sunuyor; örneğin defteriniz, bir likidite sağlayıcısı ve bir banka arasında.

Her gün küçük bir ücret farkını yutan bir tolerans, yanlış bir ücreti aylarca gizleyebilir de. Her toleransa bir sahip ve yazılı bir gerekçe verin, her kural değişikliğini kayda geçirin. Duco'nun veri hazırlama sayfası şunu listeliyor: “Yapılandırma değişikliklerinde dört göz onayı.” FCA'nın fon koruma kuralları, firmanın bir banka ya da saklama kuruluşu ekstresine karşı bulunan bir farkı araştırmasını ve onu “gereksiz gecikme olmadan” çözmek için makul olan tüm adımları atmasını şart koşar. Fark “yalnızca zamanlama farklılıklarının sonucu olarak” ortaya çıkıyorsa bu şart uygulanmaz.

Mutabakat farkının sahibi kimdir ve fark en fazla ne kadar eskiyebilir?

Mutabakat farkı (break), karşılığı bulunmayan bir kayıttır. Çoğu, geç gelen bir ekstre gibi zararsızdır; ama bazıları kayıt hatasıdır, birkaçı da paranın eksik olduğu anlamına gelir. İstisna yönetimi bunları ayıklar:

• Kategoriler: her farkı zamanlama, eksik veri ya da kayıt hatası gibi nedenine göre etiketleyin; böylece raporlar neyin sürekli ters gittiğini gösterir.
• Sahipler: her kategoriyi adı belli bir ekibe yönlendirin; örneğin nakdi hazine birimine, likidite sağlayıcısı pozisyonlarını dealing desk'e.
• Yaşlandırma: günleri farkın ilk ortaya çıktığı günden itibaren sayın, fark bir sonraki güne devrettiğinde saymaya devam edin ve belirlenmiş yaş ve tutar eşiklerinde konuyu üst kademeye taşıyın.
• Kapanış: nedeni, düzeltmeyi ve farkın kapatılmasını kimin onayladığını kaydedin.

Sağlayıcılar bunu ürünlerine yerleşik olarak sunar. Duco “iş akışı, sahiplik, yaşlandırma ve denetim için tek bir ekrandan” söz ediyor. Gresham'ın Control Cloud'u istisnaları “yaşa, değere ve karşı tarafa göre” sıralıyor.

Eski farklar paraya mal olabilir. FCA'nın fon koruma kuralları, bir firmanın bir ekstreye karşı bulunan bir farkı hemen çözemediği ve kayıtlardan birinin daha fazla para gerektiğini gösterdiği durumu kapsar. Bu durumda firma “mesele kesin olarak çözülene kadar o kaydın ya da kayıt grubunun doğru olduğunu varsaymalı” ve kendi fonlarından para yatırmalıdır. Borsanızda hafta sonları da işlem yapılıyorsa, o günlerdeki farkların sahibini belirleyin.

Bir mutabakat ürünü size ne verir ve nerede sınırına gelir?

Bunlar sağlayıcıların kendi tanımlarıdır. Duco kendini “finansal hizmetler için ajan tabanlı Operasyon platformu” olarak tanımlıyor ve devreye almanın “büyük BT projelerine gerek kalmadan birkaç gün içinde yapılabileceğini” söylüyor. Daha karmaşık mutabakatların ise “birkaç gün ya da birkaç hafta sürebileceğini” ekliyor. Gresham'ın Control Cloud'unda iş kullanıcıları kontrolleri “uzman desteğine gerek kalmadan doğrudan Control Studio'da” yapılandırıyor. AutoRek, FCA'nın CASS 6 ve 7 kuralları için “otomatik müşteri parası ve saklama varlığı mutabakatları” ile ayrı bir fon koruma çözümü satıyor. Xceptor'un SSS sayfası, müşterilerinin “ilk devreye almaları birkaç ay içinde tamamladığını” söylüyor. Smartstream, Smart Reconciliations'ı “şirket içi kurulum (on-premise) ya da SaaS olarak” satıyor.

Bir ürün, sağlayıcının önceden kurduğu konnektörleri, eşleştirme motorunu, fark yönetimi iş akışını ve denetim izini beraberinde getirir. Ama verilerinizi sağlayıcının modeline uydurursunuz ve yeni bir mutabakat, sağlayıcının uzmanlarını gerektirebilir. Kendi feed'lerinizdeki eksikleri yine siz gidermek zorundasınız. Deneme sürecinde, mutabakatlarınızdan birinin kendi dosyalarınızla kurulmuş halini görmek isteyin.

Gresham ayrıca, “mutabakat görevlerinizi uzmanlarımıza dış kaynak olarak devretmek” diye tanımladığı yönetilen bir hizmet de sunuyor. Bu hizmeti alırsanız, her günün sonucunu kimin onaylayacağını sorun.

Back office'inizdeki ya da platformunuzdaki modül mutabakat için ne zaman yeterlidir?

Zaten kullandığınız platform çoğu zaman işin bir kısmını karşılar. B2Broker, B2CORE'un, mutabakat için gerekenlerin “bağlantı ve kayıt tutma tarafını” karşıladığını söylüyor. B2CORE'un “müşteri, ödeme, mevzuat uyumu ve iş ortağı kayıtlarını mutabakatın esas aldığı sistemde tuttuğunu” belirtiyor. Stripe'ın ödeme aktarımı (payout) mutabakat raporu, “banka hesabınıza gelen ödeme aktarımlarını, ilişkili oldukları ödeme gruplarıyla ve diğer işlemlerle eşleştirmenize yardımcı olur.”

Cüzdan ve defter platformları bazı kontrolleri size bırakır. Fireblocks, vault hesaplarına para yatırma alan geliştiricilere şunu söylüyor: “Son kullanıcıların hesabına geçirmeden önce her para yatırma işleminin blockchain ile mutabakatını yapın.” Bunu, kendi kontrollerini tamamlayan “bağımsız bir kontrol” olarak niteliyor. Yukarıda alıntılanan Formance mutabakatı bakiyeleri kontrol eder, tek tek satırları eşleştirmez.

Bir modül yalnızca kendi platformunun gördüğünü görür; bu yüzden iki trading platformu ve birkaç likidite sağlayıcısı olan bir aracı kurumda, tek bir modül hepsini okumadıkça boşluklar kalır. Paranızı ya da pozisyonlarınızı tutan tüm dış tarafları listeleyin. Ardından modülün bunlardan hangilerini okuduğunu, satırları mı yoksa yalnızca bakiyeleri mi eşleştirdiğini, farklara sahip ve yaş atanıp atanmadığını ve geçmişi dışa aktarıp aktaramayacağınızı kontrol edin. Müşteri parası kontrolünü uçtan uca kapsıyorsa modül yeterli olabilir.

Kendi mutabakat sisteminizi ne zaman geliştirmelisiniz?

Kendiniz geliştirmek dar durumlarda haklıdır. Bunlardan biri, denediğiniz ürünlerin okuyamadığı verilerdir; örneğin kendi matching engine'iniz ile birkaç blockchain arasına dağılmış bakiyeler. Bir diğeri, kendi platformunuzun içindeki bir kontroldür; örneğin bir müşterinin hesabına para geçirilmeden önce her para yatırmanın teyit edilmesi. Her iki durumda da sistemin başında yıllarca kalacak mühendislere ve operasyon personeline ihtiyacınız vardır.

Eşleştirme işin küçük kısmıdır. Kendi geliştirdiğiniz bir sistem ayrıca her karşı taraf için bir konnektöre ve dosya düzeni değiştiğinde onu düzeltecek birine ihtiyaç duyar. Sürümleri ve onaylarıyla bir kural deposu, fark yönetimi iş akışı, denetim izi ve bir denetçinin okuyabileceği raporlar da gerekir.

Açık kaynaklı parçalar her zaman mutabakatı içermez. Formance çekirdek defterini MIT lisansıyla yayımlıyor, ama mutabakat modülünü yalnızca “Yıllık abonelik, ölçeğe göre özel teklif” olarak sunulan ücretli Enterprise planında listeliyor.

Bir orta yol, kendinize ait ince bir katmandır. Konnektörler, ham dosyalar ve normalize edilmiş bir veri deposu sizindir; satın alınmış bir ürün ise eşleştirmeyi ve fark yönetimi iş akışını bunun üzerinde çalıştırır. Ürün değiştirirseniz veri ve geçmişi sizde kalır.

Mutabakat sağlayıcıları ürünlerini nasıl fiyatlandırıyor?

Her sağlayıcıdan yazılı teklif isteyin. Duco, Gresham, AutoRek ve Xceptor sizden demo talep etmenizi ya da demo randevusu almanızı istiyor; Formance ise fiyatlandırma modelini rakam vermeden belirtiyor. Duco'nun mutabakat yazılımı satın almaya ilişkin SSS sayfası neleri hesaba katmanız gerektiğini sıralıyor: “Yükseltme maliyetlerini, bakım maliyetlerini, BT ve proje maliyetlerini ve maddi olmayan ya da fırsat maliyetlerini göz önünde bulundurun.”

Tek seferlik ücretlerle birlikte mevcut hacminiz için ve bunun iki katı için fiyat isteyin; yeni bir mutabakat ya da yeni bir karşı taraf formatı eklemenin maliyetini de sorun. Elinizde kalan son elektronik tabloların bir gün ürüne taşınıp taşınmayacağını bu maliyetler belirler.

Bir mutabakat sağlayıcısına bağımlılık neye benzer ve ayrılabilmek için nelerin elinizde kalması gerekir?

Bağımlılık kurallarda ve geçmişte yatar. Sağlayıcı değiştirdiğinizde eşleştirme kurallarını yeniden yazmanız gerekeceğini hesaba katın; bu yüzden onları sade bir dille belgeleyin. Fark geçmişi, yıllar sonra ihtiyaç duyabileceğiniz bir kanıttır. Yukarıda alıntılanan, yatırım kuruluşlarına yönelik AB direktifi, “denetim izi olarak kullanılabilecek” müşteri varlığı kayıtları istiyor.

Duco, “birkaç yıllık geçmiş veriyi sakladığını” ve “verileri üst akıştaki süreçlere ya da başka raporlama amaçlarıyla alt akışa da aktarabileceğinizi” söylüyor. İmzalamadan önce dışa aktarmayı test edin ve şunları sağlayıcı olmadan da okuyabileceğiniz bir formatta saklayın:

• Her kaynak dosya, geldiği haliyle ve geliş saatiyle birlikte.
• Eşleştirme kuralları ve toleranslar, değişiklik ve onay geçmişleriyle birlikte.
• Her fark; yaşı, sahibi, yorumları, nedeni ve kapanışıyla birlikte.
• Günlük onaylar ve denetçilere ya da düzenleyicilere gönderilen raporlar.

Geçiş yaparken iki sistemi farkları satır satır örtüşene kadar yan yana çalıştırın ve açık farkları ilk yaşlarıyla birlikte yeni sisteme taşıyın. Dışa aktarmayı ve bu paralel çalıştırmaya yetecek kadar uzun bir ihbar süresini sözleşmeye yazın.

Bir mutabakat sağlayıcısına ya da sistemi sizin için geliştirecek bir ekibe ne sormalısınız?

• Bankalarımızdan, saklama kuruluşlarımızdan, likidite sağlayıcılarımızdan, PSP'lerimizden ve blockchain'lerimizden hangilerini zaten okuyorsunuz ve hangi formatta?
• Tek tek satırları mı eşleştiriyorsunuz, yoksa yalnızca bakiyeleri mi?
• Bir toleransı kim değiştirebilir ve her değişiklik onaylayanıyla birlikte kayda geçiyor mu?
• Bir farkın sahibi, yaşı ve üst kademeye taşınması nasıl belirleniyor?
• Her kaynak dosyayı, kuralı, farkı ve onayı hangi formatta ve ne maliyetle dışa aktarabiliriz?
• Mevcut hacmimizde ve iki katında fiyat nedir ve her yeni mutabakat ne kadara mal olur?
• Sistemi bizim için siz geliştirirseniz: kodun sahibi kim olur ve hangi kısımlar mevcut bileşenlerinizi yeniden kullanır?

amBrain nerede devreye girer?

Bu blogu amBrain yayımlıyor. amBrain trading alanındaki işinin bazı kısımlarını üç satırla şöyle anlatıyor: “amBrain, algoritmik trading altyapısı geliştirir: emir gerçekleştirme, piyasa verisi ve işlem öncesi risk kontrolleri.” “amBrain kripto borsaları geliştirir: matching engine, cüzdanlar, para yatırma ve çekme.” “amBrain, prop trading firmaları için platformlar geliştirir: değerlendirme sınavları, trading kuralları ve muhasebe.” Bu satırların hiçbiri bir mutabakat ürününden söz etmiyor. Bunlar yalnızca hizmet tanımlarıdır.

amBrain 2019'dan bu yana yazılım geliştiriyor. Müşterileriyle nasıl çalıştığı konusunda şöyle diyor: “Üç format: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler.” Mülkiyet konusundaki satırı ise şöyle: “Müşteri, yeniden kullanılabilir bileşenlerimiz dışında ürünün ve kodun tam mülkiyetini elinde tutar.” İmzalamadan önce bu bileşenlerin adlarıyla listesini isteyin.

Bu yazı bir vaka çalışması değildir ve hiçbir müşteri işini anlatmaz. İçinde, amBrain'in herhangi bir müşteri için bir mutabakat sistemi geliştirdiğini, sattığını ya da işlettiğini söyleyen hiçbir şey yoktur. Alıntılar, yukarıda adı geçen şirketlerin, FCA'nın, ESMA'nın, Code of Federal Regulations'ın ve legislation.gov.uk'nin 12 Kasım 2026'da okunan yayımlanmış sayfalarından gelir. Yazı, amBrain ile bunlardan hiçbiri arasında bir ilişki öne sürmez, ürünlerinden hiçbirini önermez ve amBrain fiyatı ya da süresi vermez.

Bu da hukuki ya da muhasebe tavsiyesi değildir. Firmanıza uygulanan kuralları, müşteri parası ya da varlığı tuttuğunuz her pazarda bir avukatla kontrol edin. amBrain kısa listenizdeyse, ona da diğer firmalara sorduğunuz soruları sorun.