Kebijakan Privasi Aplikasi Android: Panduan 2026

Masalah kebijakan privasi sering muncul saat Anda sudah hampir rilis. Build sudah green. QA sudah sign-off. Checklist Play Console tampak hampir selesai. Lalu seseorang mengajukan pertanyaan sederhana yang menjadi blocker: apa sebenarnya yang dikumpulkan aplikasi ini, SDK mana yang menerimanya, di mana hal itu diungkapkan, dan apakah alur di dalam aplikasi sudah sesuai dengan listing?

Itulah mengapa kebijakan privasi untuk aplikasi android tidak bisa dianggap seperti dokumen legal akhir sprint. Ini adalah bagian dari proses shipping. Jika aplikasi Anda menggunakan analytics, ads, crash reporting, autentikasi, pembayaran, lokasi, kamera, kontak, atau bahkan tambahan SDK, kebijakan tersebut harus selaras dengan apa yang dilakukan code.

Masalah ini semakin krusial saat tim melakukan shipping dengan cepat. CI/CD, feature flags, staged rollouts, dan live updates membuat perilaku aplikasi berubah lebih cepat daripada siklus review tradisional. Jika kebijakan Anda masih mencerminkan alur data bulan lalu, Anda sudah tertinggal.

Table of Contents

• Mengapa kebijakan privasi aplikasi Android Anda kini lebih penting
  • Penghambat rilis yang biasanya muncul terlambat
  • Kepercayaan bergantung pada akurasi operasional
• Memahami regulasi privasi dan aturan platform utama
  • Aturan Google Play adalah persyaratan produk
  • Perubahan GDPR, CCPA, dan COPPA bagi tim aplikasi
  • Sudut pandang kepatuhan yang praktis
• Cara menyusun kebijakan privasi dari nol
  • Mulai dengan inventaris data, bukan template
  • Tulis klausul berdasarkan perilaku nyata aplikasi
  • Hal-hal yang biasanya terlewatkan
• Mempublikasikan dan menautkan kebijakan demi kepatuhan
  • Pasang kebijakan di semua permukaan yang diperlukan
  • Buat alur pengungkapan (disclosure) dengan benar
• Tantangan Live Update: Menjaga Kebijakan Tetap Sinkron
  • Mengapa kebijakan statis bermasalah di pipeline rilis cepat
  • Model sinkronisasi yang efektif untuk tim CI/CD
  • Cara menangani feature flags dan segmented rollouts
• Melangkah Maju dengan Strategi Privasi Masa Depan

Mengapa kebijakan privasi aplikasi Android Anda kini lebih penting

Penghambat rilis yang biasanya muncul terlambat

Tim sering kali tidak sengaja mengabaikan kebijakan privasi. Mereka menundanya karena fokus utama adalah pengembangan aplikasi. Lalu saat minggu rilis tiba, tim baru menyadari bahwa kebijakan tersebut tidak hanya hilang, tapi juga tidak lengkap, tidak sinkron dengan perilaku SDK, atau tidak konsisten dengan disclosure di store dan prompt izin.

Hal ini berisiko karena ekosistem telah menunjukkan betapa tidak meratanya kualitas disclosure. Sebuah studi yang menganalisis 50.000 aplikasi mobile menemukan bahwa lebih dari 77% membocorkan data sensitif, dan dicatat bahwa aplikasi Android sering kali melewati pengungkapan keamanan data secara eksplisit, menurut ringkasan riset dari Zimperium.

Saat hal itu terjadi, kebijakan privasi bukan lagi sekadar dokumen, melainkan masalah kualitas rilis. Product bertanggung jawab atas janji. Engineering bertanggung jawab atas implementasi. Compliance bertanggung jawab atas aspek hukum. Jika ketiganya tidak selaras, akan ada pihak yang hanya menebak-nebak.

Kepercayaan bergantung pada akurasi operasional

User tidak membaca setiap paragraf kebijakan, tapi mereka menyadari jika ada ketidaksesuaian. Jika aplikasi meminta lokasi saat pertama kali dijalankan tanpa konteks yang jelas, atau aplikasi utilitas sederhana ternyata mengakses kontak atau aktivitas perangkat, orang akan berasumsi yang terburuk. Dan sering kali asumsi mereka benar.

Kebijakan privasi yang solid untuk aplikasi Android menjalankan tiga fungsi sekaligus:

• Mendukung distribusi dengan menyelaraskan diri dengan persyaratan app store dan ekspektasi review.
• Membangun disiplin internal karena tim harus mendokumentasikan apa yang dilakukan oleh code dan SDK.
• Mengurangi kejutan tak terduga bagi pengguna saat izin, pelacakan, dan fitur akun muncul di aplikasi.

Aturan praktis: Jika tim engineering tidak bisa menjelaskan alur data dalam satu kalimat, kebijakan itu hampir selalu ambigu, tidak akurat, atau keduanya.

Praktik rilis cepat membuat hal ini lebih sulit. Rilis native mingguan adalah satu hal. Pipeline yang bisa mengubah JavaScript, aset, konfigurasi, dan eksposur fitur di produksi adalah hal lain. Dalam setup seperti itu, kebijakan yang ditulis sekali lalu dilupakan akan cepat usang. Sisa panduan ini berfokus pada cara menghindari pergeseran tersebut.

Memahami regulasi privasi dan aturan platform utama

Aturan Google Play adalah persyaratan produk

Bagi tim Android, area kepatuhan yang paling langsung adalah Google Play. Bagian Data safety Google meresmikan cara developer mendeskripsikan praktik data pada listing aplikasi. Google menyatakan developer harus mengungkapkan cara aplikasi mengumpulkan, membagikan, dan menangani berbagai jenis data, serta aplikasi harus meminta izin sebelum mengakses data tertentu setelah download, sebagaimana dijelaskan dalam panduan Google Play Data safety.

Hal itu mengubah percakapan di dalam tim. Privasi bukan cuma halaman legal di situs Anda. Ini juga mencakup metadata di listing store, perilaku izin saat runtime, dan jalur code aktual yang mengumpulkan atau membagikan data. Jika salah satunya berbeda, Anda sudah membuat inkonsistensi yang bisa dilihat pengguna dan reviewer.

Google Play harus diperlakukan seperti spesifikasi produk. Listing, permintaan izin, kebijakan, dan perilaku runtime harus mendeskripsikan aplikasi yang sama.

Tim yang sering melakukan rilis juga harus memperhatikan disiplin rilis terkait kebijakan dan deklarasi di store. Referensi operasional yang berguna adalah panduan ini tentang kepatuhan Google Play dan strategi update, terutama jika proses rilis Anda sudah bergantung pada otomatisasi.

Perubahan GDPR, CCPA, dan COPPA bagi tim aplikasi

Kerangka hukum itu penting karena dapat mengubah apa yang perlu Anda ungkapkan dan kontrol apa yang diharapkan pengguna.

GDPR menuntut tim untuk spesifik soal tujuan. Kalimat “Kami mengumpulkan data analitik untuk meningkatkan aplikasi” sering kali terlalu umum. Anda perlu tahu event mana, prosesor mana, logika retensi apa, dan apakah ada yang mendukung profiling atau iklan.

CCPA dan CPRA memaksa pemikiran yang lebih jelas tentang kategori dan pembagian data ke pihak ketiga. Jika stack monetisasi atau alat pengukuran Anda memindahkan data ke vendor lain, kebijakan Anda harus menjelaskan hubungan tersebut dengan bahasa yang lugas.

COPPA adalah bagian di mana banyak tim harus berhenti dan meminta tinjauan hukum ahli. Jika produk ditujukan untuk anak-anak, sekadar menggunakan template aplikasi konsumen umum adalah langkah yang buruk.

Most important takeaway: ungkapkan berdasarkan pemrosesan nyata, bukan berdasarkan apa yang terdengar minimal.

Bagi tim yang beroperasi di berbagai wilayah, melacak perubahan ekspektasi privasi internasional di satu tempat akan sangat membantu. Ringkasan tentang רגולציית פרטיות לעסקים בינלאומיים adalah referensi lintas batas yang berguna saat aplikasi Android Anda melayani berbagai pasar.

Sudut pandang kepatuhan yang praktis

Developer tidak perlu menghafal teks hukum. Mereka butuh model kerja yang mengubah aturan menjadi keputusan rilis.

Gunakan checklist ini sebelum menyusun atau memperbarui kebijakan:

• Cek pengumpulan data. List setiap kategori data user dan perangkat yang dapat diakses aplikasi atau SDK yang tertanam.
• Cek tujuan penggunaan. Hubungkan setiap elemen data dengan fitur atau kebutuhan operasional yang saat ini ada.
• Cek pembagian data. Sebutkan setiap processor, vendor infrastruktur, alat analytics, mitra iklan, atau alat support yang menerima data tersebut.
• Cek hak pengguna. Tentukan cara user meminta akses, penghapusan, koreksi, atau perubahan persetujuan (consent).
• Cek audiens. Konfirmasi apakah aplikasi menjangkau anak-anak, pengguna EU, pengguna California, atau lingkungan pelanggan yang teregulasi.

Pendekatan ini lebih berguna daripada mencoba menulis halaman hukum yang panjang dari ingatan. Ini mengubah privasi menjadi sistem yang bisa Anda kelola.

Cara menyusun kebijakan privasi dari nol

Mulai dengan inventaris data, bukan template

Cara paling bersih untuk menyusun kebijakan privasi aplikasi Android adalah dengan mulai dari perilaku aplikasi, bukan sekadar template. Alur kerja praktisnya adalah inventarisasi setiap tipe data yang dapat diakses aplikasi atau SDK-nya, petakan setiap elemen data ke fitur yang membutuhkannya, dokumentasikan setiap pihak ketiga yang menerima data, tentukan kontrol keamanan, serta tentukan retensi dan penghapusan, seperti yang diuraikan dalam alur kerja kebijakan privasi Android Termly.

Urutan itu penting. Jika Anda mulai dengan template, Anda akan menulis bahasa yang terlalu umum dan mengisi celah dengan asumsi. Jika Anda mulai dengan inventarisasi data, dokumen tersebut akan cukup spesifik untuk lolos tinjauan tim engineering, produk, dan legal.

Mulailah inventarisasi Anda dengan kategori yang biasanya terlewatkan oleh developer:

• pengumpulan data SDK seperti analytics, attribution, ad mediation, crash reporting, session replay, support chat, dan tools fraud
• Input dengan izin akses (permission-gated) seperti lokasi, kamera, mikrofon, kontak, SMS, dan status telepon
• Data latar belakang dan turunan termasuk aktivitas aplikasi, aplikasi terinstal, sinyal penggunaan perangkat, dan data terkait akun di berbagai layanan

Banyak tim baru menyadari draf pertama kebijakan mereka setelah memeriksa daftar dependency.

Tulis klausul berdasarkan perilaku nyata aplikasi

Setelah inventaris selesai, susun setiap bagian kebijakan dari spreadsheet atau sistem record yang sama. Jangan tanya, “Apa yang biasanya ada di kebijakan privasi?” Tapi tanyalah, “Apa yang dilakukan aplikasi ini saat ini?”

Struktur praktisnya adalah sebagai berikut:

1. Data yang kami kumpulkan
   Jelaskan kategori menggunakan bahasa yang mudah dipahami user. Contoh: informasi akun, data terkait pembayaran, lokasi, pesan support, informasi perangkat, event penggunaan.

2. Cara kami menggunakan data Kaitkan penggunaan dengan fungsi produk. Autentikasi, pencegahan fraud, customer support, analytics, pengiriman fitur, billing, dan kepatuhan hukum semuanya masuk di sini jika berlaku.

3. Berbagi dengan pihak ketiga
   Identifikasi jenis vendor yang terlibat dan alasan mereka menerima data. Hosting, analytics, pembayaran, messaging, customer support, dan crash reporting adalah contoh umum.

4. Keamanan dan retensi
   Jelaskan perlindungan secara kualitatif kecuali jika tim keamanan Anda telah menyetujui bahasa yang spesifik. Sebutkan berapa lama data disimpan atau kriteria yang digunakan untuk menentukan masa retensi.

5. Pilihan dan hak pengguna
   Sertakan kontrol akun, jalur penghapusan, pengaturan consent, jalur kontak support, dan penanganan hak khusus wilayah jika relevan.

Berikut contoh gaya penulisan yang berguna:

Kami mengumpulkan informasi akun seperti alamat email dan detail login untuk membuat dan mengamankan akun Anda. Kami juga mengumpulkan informasi penggunaan aplikasi untuk menjalankan fitur, mendiagnosis error, dan meningkatkan layanan. Jika Anda mengaktifkan fitur berbasis lokasi, kami hanya mengumpulkan data lokasi untuk fitur tersebut.

Ini lebih baik daripada teks yang ambigu karena mengaitkan data dengan fungsinya.

Bagi tim yang meninjau contoh bagaimana perusahaan mendeskripsikan komitmen privasi secara publik, Komitmen perlindungan data Formbricks adalah referensi berguna untuk tone dan struktur. Jangan menyalinnya. Gunakan untuk mengkalibrasi kejelasan.

Praktik engineering terkait adalah mendokumentasikan alur yang sama di catatan arsitektur aplikasi Anda. Panduan tentang penanganan data pengguna di aplikasi Capacitor adalah pelengkap yang baik jika stack mobile Anda mencakup web dan native.

Hal-hal yang biasanya terlewatkan

Kegagalan terbesar saat menyusun bukanlah prosa yang buruk, melainkan alur data yang terlewat.

Hal yang sering terlewatkan meliputi:

• Perilaku SDK yang tersembunyi. Aplikasi itu sendiri tampak tidak berbahaya, tetapi sebuah library mengirim identifier, crash payload, atau data event ke luar perangkat.
• Penggunaan ulang data akun. Tim menggunakan informasi akun di berbagai layanan untuk dukungan, iklan, pencegahan fraud, atau analytics tanpa mencerminkan tiap tujuan dengan jelas.
• Ketidakjelasan retensi data. Kebijakan tersebut menyatakan data dikumpulkan, namun tidak menjelaskan berapa lama data disimpan atau bagaimana proses penghapusannya.
• Perubahan fitur (feature drift). Produk sudah menghapus sebuah fitur berbulan-bulan lalu, tapi kebijakan masih menyebutkannya. Atau lebih buruk, ada alur baru yang rilis tapi tidak ada di kebijakan.

Kebijakan privasi yang baik bukan soal bahasa hukum yang rapi, melainkan soal apakah peta engineering Anda sudah lengkap.

Itulah mengapa saya lebih suka kepemilikan review dibagi bersama. Engineering memverifikasi pengumpulan dan pembagian data. Product memverifikasi tujuan dan alur pengguna. Compliance atau legal memverifikasi kecukupan hukum. Kebijakan yang hanya ditulis oleh satu grup biasanya tidak lengkap.

Mempublikasikan dan menautkan kebijakan demi kepatuhan

Dokumen kebijakan privasi di Notion atau Google Docs tidak membantu kepatuhan. Pengguna dan reviewer harus bisa mengaksesnya di tempat yang tepat, dan alur persetujuan aplikasi harus dilakukan sebelum pengumpulan data dimulai.

Aturan gaya Google memperjelas hal ini. Link kebijakan saja tidak cukup jika aplikasi mengumpulkan data pribadi atau sensitif. Kebijakan harus terlihat di listing store dan di dalam aplikasi, serta pengumpulan tidak boleh dimulai sebelum ada persetujuan eksplisit. Navigasi back atau home tidak dianggap sebagai persetujuan, menurut ringkasan persyaratan pengungkapan utama Android ini.

Tempatkan kebijakan di semua permukaan yang diwajibkan

Tim development umumnya harus mempublikasikan kebijakan di tiga tempat:

• URL web publik. Host di halaman stabil yang Anda kontrol. Hindari dokumen sementara, workspace privat, atau URL yang berisiko berubah setelah redesign.
• Listing Google Play. Tambahkan URL publik yang sama pada field Play Console yang relevan.
• Titik akses in-app. Letakkan di tempat yang mudah ditemukan pengguna, biasanya di Settings, Account, About, atau Privacy.

Jika aplikasi punya alur sign-up, pembayaran, atau yang banyak meminta izin, tambahkan juga link kontekstual di sana. Pengguna tidak perlu berburu di menu untuk memahami alasan sebuah izin diminta.

Bangun alur disclosure dengan benar

Alur runtime sama pentingnya dengan halaman yang dihosting. Jika aplikasi Anda mengakses data sensitif, polanya harus seperti ini:

1. Tampilkan disclosure in-app yang jelas.
2. Jelaskan data apa yang terlibat dan alasannya.
3. Minta opt-in eksplisit
4. Baru setelah itu, aktifkan API atau SDK yang relevan.

Alur yang buruk seperti ini: instal aplikasi, SDK inisialisasi, pengumpulan data dimulai saat launch, dan halaman privasi tersembunyi di dalam settings. Ketidaksesuaian implementasi seperti inilah yang memicu masalah.

Panduan ini perlu ditinjau bersama tim engineering dan product:

Beberapa kesalahan saat publishing sering terjadi berulang kali:

• Link store mengarah ke homepage bukannya ke halaman kebijakan itu sendiri.
• Link in-app baru muncul setelah sign-in, padahal pengumpulan data sudah dimulai lebih awal.
• Pengungkapan informasi digabung ke dalam teks terms bukannya dibuat spesifik untuk pengumpulan data sensitif.
• Consent is implied by continuation bukannya dikumpulkan melalui tindakan konfirmasi yang jelas.

Jika Anda hanya ingin memperbaiki satu hal di sini, perbaikilah urutannya. Pengungkapan dan persetujuan harus dilakukan sebelum pengumpulan data, bukan setelahnya.

Tantangan Live Update: Menjaga Kebijakan Tetap Sinkron

Mengapa kebijakan statis bermasalah dalam pipeline rilis cepat

Panduan privasi umum biasanya menjadi kurang relevan pada tahap tertentu. Panduan tersebut memberi tahu apa yang harus ada dalam kebijakan privasi, tetapi tidak cara menjaganya tetap akurat saat aplikasi Anda berubah di luar siklus review store.

Kesenjangan itu nyata. Panduan yang ada tidak menjawab bagaimana developer yang menggunakan platform live update harus menangani kepatuhan saat mengirimkan perbaikan tanpa review app store. Pertanyaan terbuka meliputi apakah kebijakan harus diperbarui sebelum live update menyebarkan code penanganan data baru, dan audit trail apa yang dibutuhkan tim teregulasi saat update mengubah alur data tanpa pengawasan store, sebagaimana dicatat oleh diskusi Free Privacy Policy mengenai persyaratan kebijakan aplikasi Android.

Kebijakan statis mengasumsikan versi aplikasi yang stabil. CI/CD tidak bekerja seperti itu. Feature flags, segmented rollouts, remote config, dan live bundle delivery dapat mengubah apa yang dilihat pengguna dan jalur data yang dieksekusi. Jika proses privasi Anda masih berasumsi “update kebijakan saat versi native berubah,” Anda akan melewatkan perubahan material.

Model sinkronisasi yang efektif untuk tim CI/CD

Solusinya adalah memperlakukan privasi sebagai metadata rilis.

Setiap update yang dapat memengaruhi pengumpulan, pembagian, penggunaan izin, atau tujuan data harus melalui pengecekan dampak privasi dalam pipeline. Ini bukan berarti setiap rilis butuh tinjauan hukum, melainkan setiap rilis butuh klasifikasi.

Model praktisnya adalah sebagai berikut:

Pendekatan ini paling efektif jika release pipeline membawa metadata terstruktur. Contohnya: “memakai permission baru,” “menambah SDK pihak ketiga,” “mengubah logika retensi,” “mengubah tujuan,” atau “tidak ada perubahan privasi.” Jika engineer harus memilih satu sebelum merge atau promote release, Anda menciptakan akuntabilitas tanpa memperlambat setiap deploy.

Saran operasional: beri versi pada kebijakan seperti code, tautkan setiap revisi kebijakan yang dipublikasikan ke release atau channel yang membawa perubahan, dan simpan catatan itu bersama-sama.

Tim yang memakai live bundle delivery juga perlu paham mekanisme bagaimana update sampai ke perangkat. Penjelasan tentang cara kerja live update untuk Capacitor membantu menjelaskan mengapa sinkronisasi kebijakan tidak bisa hanya bergantung pada review store. Praktiknya, salah satu opsi bagi tim yang merilis aplikasi Capacitor adalah Capgo, yang mengirimkan signed web bundles ke channel serta menyimpan riwayat versi dan kontrol rollout. Mekanisme ini berguna untuk traceability kebijakan jika Anda memetakan identifier rilis ke revisi kebijakan.

Cara menangani feature flags dan segmented rollouts

Feature flags memunculkan pertanyaan sulit lainnya. Jika hanya sebagian user yang menerima fitur pengumpulan data, apa yang harus tertulis di kebijakan?

Pendekatan praktis yang paling aman adalah:

• Ungkapkan praktik data aktif kepada audiens yang menerimanya. Jika sebuah cohort produksi mendapatkan alur data baru, alur tersebut harus sudah dicakup sebelum atau saat mulai aktif.
• Jangan bersembunyi di balik code yang tidak aktif. Jika fitur tersebut ada di code tetapi belum aktif di mana pun, dokumentasikan secara internal, bukan sebagai pengumpulan data pengguna saat ini.
• Hubungkan prompt dengan aktivasi, bukan instalasi. Jika feature flag mengaktifkan izin baru atau pengumpulan data sensitif di kemudian hari, tampilkan disclosure dan dapatkan consent pada saat aktivasi tersebut.
• Snapshot per channel. Beta, staging, stream pelanggan enterprise, dan produksi mungkin memerlukan snapshot kebijakan yang berbeda atau setidaknya catatan internal yang berbeda.

Masalahnya adalah kebijakan tunggal yang terlalu luas dan hanya menyatakan secara samar bahwa aplikasi mungkin mengumpulkan apa pun di masa mendatang. Hal ini mungkin terasa lebih aman secara internal, namun mengurangi transparansi dan tetap berisiko gagal jika perilaku runtime dan alur persetujuan tidak sesuai dengan teks tersebut.

Untuk tim yang teregulasi, saya juga mewajibkan tiga artefak untuk setiap perubahan privasi yang signifikan: diff code, diff kebijakan yang telah disetujui, dan perubahan pengungkapan (disclosure) kepada pengguna. Tanpa itu, proses rekonstruksi audit akan menjadi sangat sulit.

Melangkah Maju dengan Strategi Privasi yang Future-Proof

Kebijakan privasi yang kuat untuk aplikasi Android adalah sebuah proses pemeliharaan, bukan sekadar dokumen sekali jadi. Tim akan mengalami masalah jika menganggapnya hanya sebagai teks hukum di akhir persiapan rilis, alih-alih sebagai catatan operasional tentang apa yang dilakukan aplikasi.

Pendekatan yang tahan lama sangatlah sederhana:

• Inventarisasi alur data sebelum menyusun draf
• Petakan setiap tipe data ke fitur atau tujuan yang aktif
• Tinjau setiap SDK dan vendor, bukan hanya code pihak pertama
• Publikasikan kebijakan di tempat yang diharapkan pengguna dan Google
• Batasi pengumpulan data sensitif dengan pengungkapan jelas dan persetujuan eksplisit
• Versikan perubahan kebijakan bersamaan dengan perubahan rilis
• Tambahkan pengecekan privasi ke CI/CD, feature flags, dan workflow live update

Disiplin tersebut memberikan hasil lebih dari sekadar kepatuhan. Hal ini mempermudah analisis rilis, mempertajam keputusan produk, serta memberikan jawaban yang kuat bagi tim support dan security saat pengguna bertanya tentang data apa yang dikumpulkan dan alasannya.

Jadikan privasi sebagai bagian dari release engineering. Tim yang menerapkannya akan merilis aplikasi yang lebih bersih.

Jika tim Anda merilis aplikasi Capacitor atau Electron dan butuh perubahan kebijakan privasi yang selaras dengan update produksi yang cepat, Capgo layak dievaluasi sebagai bagian dari workflow tersebut. Ini memberikan tim kontrol live updates, riwayat versi, manajemen rollout berbasis channel, dan observability rilis, yang membantu menghubungkan perubahan perilaku aplikasi dengan pembaruan kebijakan secara otomatis daripada mengandalkan ingatan manual.

Ditulis dengan Alat peringkat SEO

Lanjutkan dari Kebijakan Privasi untuk Aplikasi Android: Panduan 2026

Jika Anda menggunakan Kebijakan Privasi Aplikasi Android: Panduan 2026 untuk merencanakan keamanan dan kepatuhan, hubungkan dengan Enkripsi untuk detail implementasi pada Encryption, Kepatuhan untuk detail implementasi pada Compliance, Capgo Pemindai Keamanan untuk alur kerja produk di Capgo Security Scanner, Keamanan Capgo untuk alur kerja produk di Capgo Security, dan Capgo Pusat Kepercayaan untuk workflow produk di Capgo Trust Center.