Makro backtest’in revize edilmiş istihdam raporunu işlem yaptı

Bordro filtresi stratejisini geliştiren sevgili dostum,

Basit bir kural oluşturdunuz: ABD istihdam raporundan sonra, aylık bordro artışı 175,000’i aşarsa stratejiniz bir hisse senedi ETF’sini 5 seans boyunca tutuyor. Aksi hâlde nakitte kalıyor. Girişi hisse senedi piyasası açıldıktan sonraya planladınız, işlem maliyetlerini eklediniz ve eşiği sabit tuttunuz. Ardından geçmiş bordro serisini indirip tüm sinyalleri bununla yeniden oluşturdunuz.

Geriye kalan sorununuz indirdiğiniz veriler. Geçmiş bir ekonomik seri, stratejinizin işlem yaptığı varsayılan tarihlerde henüz mevcut olmayan revize edilmiş tahminleri içerebilir. Bir makro sinyali dürüstçe geriye dönük test etmek için her karar anında mevcut olan sürümü kullanmanız gerekir. Girişi 1 bar ötelemek, 2 ay sonra yayımlanan bir rakamı düzeltmez.

Ocak verinizin birden fazla doğum günü var

Şu kurgusal yayımlama geçmişini ele alalım. Bu tarihler ve bordro değişimleri işleyişi örneklemek içindir; açıklanmış ekonomik sonuçlar değildir.

İndirdiğiniz veri Ocak için +210,000 gösteriyorsa, tekrar oynatımınız Şubat’ta ETF’ye girer. Gerçek kuralınızsa nakitte kalırdı. Her fiyat, emir zaman damgası ve komisyon doğru olsa bile, bu işlemin tamamı hayalidir.

Bu veri sızıntısının performansı mutlaka iyileştirdiğini varsayamazsınız. Revizyonlar kârlı işlemler yaratabilir, zarar ettiren işlemler yaratabilir ya da her ikisini de ortadan kaldırabilir. Sorun şu: simülasyonunuz, stratejinizin o sırada soramayacağı bir soruyu yanıtlıyor.

Üstelik Ocak, yalnızca ölçümün ait olduğu dönemdir. Ölçümü öğrendiğiniz tarih değildir. Ocak 1 olarak etiketlenmiş bir satır, onu Ocak 1’de işlem yaparken kullanma hakkı vermez.

Her değer için kullanılabilirlik geçmişi tutun

Araştırma tablonuzda aydan ve sayıdan fazlası bulunmalı. Referans dönemini, değeri, yayım zaman damgasını, sürüm kimliğini ve kaynağı saklayın. Veriyi düzenli olarak topluyorsanız sisteminizin yayımı ne zaman aldığını da kaydedin. Eski sürümlerin değerlerini yerinde güncellemek yerine önceki sürümleri koruyun.

Karar zaman damgasında, kullanılabilirlik zaman damgası karar anından ileri olmayan her gözlemin en yeni uygun sürümünü seçin. Ardından özelliklerinizi bu yeniden oluşturulmuş anlık görüntüden hesaplayın.

5 seanslık elde tutma süreniz bu kayıt tutma işini isteğe bağlı hâle getirmez. Daha temkinli bir giriş zamanı seçmek için size daha fazla alan sağlar; revizyonlara erkenden erişim sağlamaz.

Eski araştırmalarda, kendi sisteminizin veriyi aldığına dair kayıt olmadan, yayımlanma saatine ilişkin kanıtınız bulunabilir. Bu ayrımı açıkça koruyun. Belgelenmiş bir yayım zamanından sonra, belirtilen bir gecikmeyle erişim varsayabilirsiniz. Ancak bu varsayımı ölçülmüş geçmiş teslimat gibi sunamazsınız.

Zaman dilimini dikkate alan bir zaman damgası da kullanmalısınız. Yayımın belgelenmiş yerel saatini saklayıp doğru biçimde dönüştürün; New York için sabit bir UTC farkı yaz saati uygulamasındaki değişikliklerde hata verir. Gelecekteki kendinize bu küçük iyiliği yapın. Eylül’deki siz, Mart’taki sizin date_actual_final2 adlı sütununun ne anlama geldiğini çözmek zorunda kalmasın.

Hareketli özellikleriniz için tüm sürüm geçmişi gerekir

Sabit eşiği “bordro artışı, önceki 12 aylık ortalamayı aşarsa” kuralıyla değiştirdiğinizi varsayalım. Artık önceki gözlemlerin o karar anındaki hâline, o tarihe kadar yayımlanmış revizyonlar dâhil, ihtiyacınız var.

Her ayın ilk yayımını sonsuza dek kullanmak farklı bir özellik tanımlar. İlk açıklamaların geçmişini istiyorsanız bu geçerli bir tasarım olabilir. Ancak belirli bir sabah görülebilen ekonomik geçmişi yeniden oluşturmaz; çünkü o sabahın bilgi kümesi önceki ayların revizyonlarını zaten içerebilir.

Aylık bordro değişimlerini istihdam düzeylerinden türetiyorsanız, farkı almadan önce ilgili sürümün düzey serisini yeniden oluşturun. Yeni yayımlanan bir düzeyi önceki ayın eski sürümdeki düzeyiyle karıştırmak, yayımlanmış hiçbir anlık görüntüde bulunmayan bir değişim ortaya çıkarabilir.

Bu nedenle özelliğinizin neyi ifade ettiğini belirtmeniz gerekir: ilk açıklamaları mı, o ana kadar mevcut en güncel ekonomik görünümü mü, yoksa revizyonların kendisini mi? “Bordro artışı” ifadesi, çok fazla şeyi belirsiz bırakıyor.

10 yıllık geçmişi yeniden çalıştırmadan önce bir yayımı düzeltin

Başlangıç için, birçok ekonomik serinin sürüm geçmişini sunan ALFRED’e bakabilirsiniz. Kullandığınız seri ve dönemin kapsama dâhil olduğunu kontrol edin. Tek başına sürüm tarihi, gün içindeki kullanılabilirliği kanıtlamaz; aynı gün sinyalinde kullanmadan önce yayımlanma saatini belgeleyen kaynaklarla bunu destekleyin.

İlk denetiminizde 1 yayım seçip elle yeniden oluşturun:

1. Arşivlenmiş yayımı bulun ve yayımlanma zaman damgasını, referans ayını ve ilk değeri kaydedin.
2. Stratejinizin girişten önce almış olacağı girdi anlık görüntüsünü yeniden oluşturun.
3. Sinyali elle hesaplayıp tekrar oynatımınızla karşılaştırın.
4. Veri deposuna daha sonraki bir revizyonu ekleyin ve önceki kararın değişmediğini doğrulayın.

Bu son kontrol, otomatik bir araştırma hattında özellikle yararlıdır. Araştırma ajanınıza özellik değerleriyle birlikte anlık görüntü kesim zamanını ve seçilen sürüm kimliklerini verin. Alttaki veritabanı büyüdükten sonra bile bir işlemi belirli bir yayıma kadar izleyebilmek için yeterli kanıta ihtiyacınız var.

Bu tek karar yeniden üretilebildiğinde, geçmişi yeniden çalıştırın ve getirileri karşılaştırmadan önce sinyal uyuşmazlıklarını inceleyin. Düzeltmenin yarattığı, ortadan kaldırdığı veya zamanını değiştirdiği girişleri sayın. Değişen bu kararlardan, tek bir önce-sonra Sharpe karşılaştırmasından daha fazla şey öğrenirsiniz.

Şubat işleminiz, Şubat ayındaki bilgilerle ayakta kalmalı. Nisan revizyonunu Nisan’da bırakın.