Словник для розробників Fintech

Фінансові технології знаходяться на перетині програмного забезпечення та фінансових систем. Якщо ви створюєте платіжні платформи, торгові системи, банківські API або програмне забезпечення для обліку, ви зіткнетеся зі спеціалізованим словником, який поєднує фінанси та інженерію. Цей посібник охоплює основні терміни, які кожен розробник фінансових технологій повинен чітко комунікувати.

---

Reconciliation

** Прирівнювання ** — це процес перевірки того, чи збігаються два набори фінансових записів, наприклад, підтвердження того, що операції, записані у вашій внутрішній системі, збігаються з операціями, про які повідомляє банк або процесор платежу.

• “Кожної ночі, завдання порівнює нашу внутрішню книгу зі звітом про виплати Stripe. Будь-яка невідповідність викликає попередження для фінансової команди.”*
• “Помилки прирівнювання зазвичай спричиняються відмінностями у часі, дублікатами записів або помилками округлення при перетворенні валют.” *

---

Settlement

** Розрахунок ** це процес переказу коштів між сторонами для завершення фінансової операції. Розрахунок може бути негайним (брутто розрахунок в реальному часі, або RTGS) або відкладеним (зазвичай наступного робочого дня, або T + 1 / T + 2).

“Платіжки карткою розраховуються на основі T+1 — гроші з’являються на рахунку продавця в робочий день після транзакції.”

• “Ми використовуємо рахунок розрахунків для пакетного оброблення щоденних транзакцій і розрахунків раз на день, а не для обробки сотень окремих переказів.” *

---

Ledger

** Бухгалтерський облік ** - це запис фінансових операцій. У програмному забезпеченні, бухгалтерський облік часто є таблицею бази даних або службою, яка записує кожен дебет і кредит, підтримуючи точний баланс.

• “Наша бухгалтерія з подвійним записом записує кожну транзакцію як дебет на одному рахунку і відповідний кредит на іншому. Сума всіх записів завжди дорівнює нулю.”*
• “Ми створили незмінну бухгалтерську книгу — записи ніколи не вилучаються або оновлюють, їх лише додають. Це дає нам повний аудиторський слід.»*

---

Idempotency

** Ідемпотентність ** означає, що виконання одного і того ж запиту декілька разів дає той самий результат, що і виконання цього запиту один раз. У платіжних системах, ідемпотентність є критичним для запобігання подвійних платежів, коли запити повторюються через помилки мережі.

• “Кожен запит API платежу повинен містити ключ ідемпотентності. Якщо ви спробуєте знову з тим же ключем, сервер поверне початкову відповідь без повторної обробки платежу.”*
• “Без ключів ідемпотентності, затримка, після якої слідує повторна спроба, може призвести до подвійного обчислення клієнта.” *

---

2002 рік 22

** ISO 20022** — це міжнародний стандарт для фінансових повідомлень — спільна мова для обміну даними між фінансовими установами. Він поступово замінює старі стандарти, такі як повідомлення SWIFT MT, і приймається CHAPS, SEPA та іншими основними платіжними системами.

• “Ми переносимо наші платіжні повідомлення на ISO 20022 перед кінцевим терміном SWIFT. Новий формат містить набагато більшу кількість даних, включаючи повну інформацію про переказ». * “Повідомлення ISO 20022 засновані на XML і структуровані — вони більш докладні, ніж повідомлення MT, але набагато простіше аналізувати і перевіряти програмно.”

---

Протокол FIX

Протокол **FIX (Financial Information eXchange) ** є стандартом повідомлень, який використовується в електронній торгівлі для обміну інформацією про операції з цінними паперами у реальному часі. Це домінуючий протокол для маршрутизації замовлень між брокерами, біржами і фірмами, що здійснюють покупку.

• “Система керування замовленнями надсилає накази купівлі і продажу на біржу через FIX 4. 4. Кожне повідомлення містить ідентифікатор інструменту, кількість, ціну і тип замовлення.”*
• “FIX — це протокол з низькою затримкою, який підтримує двійкові файли. У високочастотній торгівлі, навіть мікросекунди затримки мають значення, і FIX був розроблений з цим у виду.”*

---

Clearing

** Кліринг ** це процес прирівнювання наказів між сторонами, що здійснюють операції, перед розрахунком — підтвердження деталей операції і забезпечення того, щоб обидві сторони мали необхідні кошти або цінні папери для її завершення.

• “Після виконання операції, вона проходить через розрахунок. Клірингова палата діє як контрагент як для покупця, так і для продавця, гарантуючи розрахунок навіть якщо одна зі сторін не виконає своїх зобов’язань. ”*
• “Кліринг додає рівень управління ризиками між виконання торгів і розрахунку. Це обов’язково для більшості біржових інструментів.»*

---

Escrow

** Escrow ** це угода, в якій довірена третя сторона зберігає кошти або активи від імені двох сторін до виконання певних умов. У програмному забезпеченні, Escrow-механізми поширені в ринкових і P2P платіжних платформах.

• “Коли покупець робить замовлення на ринку, оплата утримується в депозиті. Гроші виплачуються продавцю тільки після того, як покупець підтверджує доставку. ”*
• “Ми реалізували службу Escrow, використовуючи віртуальний рахунок для кожної транзакції. Фонди залишаються на депозитному рахунку до закриття вікна спору. “*

---

Chargeback

** Chargeback ** відбувається, коли клієнт спірує транзакцію зі своїм банком, і банк повертає платіж, відновлюючи кошти від торговця. Зворотні платежі є дорогими і можуть призвести до штрафів для торговців з високими ставками.

• “Наша модель виявлення шахрайства позначає транзакції, які можуть призвести до зворотних зобов’язань. Зменшуючи високоризикові транзакції, ми зберігаємо рівень зворотного зобов’язання нижче порогу в 1%, встановленого Visa. “*

---

Практичні фрази для розробників Fintech

• “В результаті нічного прирівнювання було виявлено розбіжність у 240 фунтів — це виявилося поверненням, яке було оброблено після запуску пакету розрахунків.”
• • “Завжди передавати ключ ідемпотентності під час виклику API платежів. Якщо ви цього не зробите, повторні спроби створять дублікати платежів.”*
• • “Реєстр можна лише додавати. Ми ніколи не оновлюватимемо або не вилучаємо рядки — замість цього ми випускаємо виправляючий запис».*
• “Ми переходимо на ISO 20022 для підтримки більш багатих платіжних даних і відповідності з графіком міграції SWIFT.”
• “Кліринговий центр вводить управління ризиками контрагента між торгівлею і розрахунками.”

---

Словник Fintech з’єднує два світи — фінанси і програмне забезпечення. Освоєння цих термінів допоможе вам читати документацію API, обговорювати дизайн системи з партнерами з платежу, спілкуватися з командами з відповідності і фінансів, а також створювати надійні фінансові системи, які надійно і безпечно обробляють гроші.

Складання графіків: графіки для окремих видів діяльності

Основний словник фінансових технологій - примирення, розрахунок, книга і так далі - є життєво важливим для будь-кого, хто створює системи в цьому просторі. Однак, просто знати визначення недостатньо; йдеться про те, як ви ефективно комунікуєте ці концепції в різноманітній команді. Для розробників, які вивчають професійну англійську, нюанси у фразування можуть бути особливо викликом. Розгляньте різницю між «ми повинні примирити розбіжності» і «є невідповідності, які вимагають вирішення». Перша функціональна, але друга передає невідкладність і передбачає глибше дослідження. Аналогічно, заява про те, що транзакція зазнала невдачі через «дуплікатну обробку» може звучати тупо; оформлення її як «перевірка ідемпотентності запобігла дублікатним транзакціям» демонструє більш складне розуміння основного дизайну системи.

Це не просто формальність; це про ясність. При обговоренні питань з зацікавленими сторонами - особливо з тими, хто може не мати технічного досвіду - використання точної і добре структурованої мови будує довіру і уникає непорозумінь. Уявіть, що ви пишете опис запитів на витягування, щоб пояснити, чому розрахунок платежу зазнав невдачі. Просто сказати «Оплата не пройшла» не допоможе. Замість цього, розгляньте: « Через несподіваний тайм- аут під час обробки повідомлення ISO 20022, спроба розв’ язання була автоматично повторена згідно з нашою політикою ідемпотентності. » Остаточне підтвердження розрахунку тепер буде відображено у бухгалтерській книзі. » Ця інформація показує вам, що ви розумієте складність цієї операції і надає контекст для зміни. Іншим поширеним сценарієм є розмови Slack. Молодший розробник може ввести «Ця річ не працює!» — хоча це зрозуміло, але йому бракує точності. Професійнішим підходом буде: «Я стикаюся з помилкою під час обміну протоколом FIX; Я підозрюю потенційну проблему з мережевим з’єднанням або форматуванням повідомлень»

Крім того, пам’ятайте, що різні культури мають різні рівні прямоти в спілкуванні. Деякі команди можуть віддавати перевагу більш непрямій мові при обговоренні проблем, зосереджуючись на рішеннях, а не на невдачах. Важливо бути пристосовуваним і спостерігати, як спілкуються ваші колеги, вивчаючи їхню фразу і відповідно пристосовуючи свою. Ключовим є створення спільного розуміння термінології, але це виходить за рамки простого знання визначення; мова йде про оволодіння * способом * виразити ці ідеї. Не бійтеся просити про пояснення - справжня цікавість і бажання вчитися універсально цінуються.

Нарешті, при обговоренні технічного боргу або спадкових систем, такі фрази, як «це потребує рефакторингу» можуть звучати відверто. Більш конструктивним підходом буде: « Поточна архітектура представляє виклики з точки зору масштабованості і підтримки; ми повинні дослідити можливості модернізації, вирівняні з нашою стратегією ISO 20022. » Ці невеликі зміни у формулюванні демонструють професіоналізм і сприяють спільному, продуктивному середовищу.

# Example using jq to inspect an ISO 20022 message (simplified)
jq '.messageType' iso20022_message.json