Англійська для інженерів з інтеграції Fintech: Open Banking, PSD2, і Payment API Vocabulary
Open banking, SCA, idempotency key, reconciliation — англійська лексика, яку використовують інженери з інтеграції фінансових технологій у викликах API, технічних викликах і оглядах платежів.
Інтеграція Fintech знаходиться на перетині фінансового регулювання і програмного забезпечення - і має свій власний щільний словник англійською мовою. Незалежно від того, чи ви спілкуєтеся з британським банком, переглядаєте потоки платежу з менеджером продукту або зневаджуєте помилковий webhook, правильні слова допоможуть вам звучати достовірно і точно спілкуватися.
Цей пост навчає основного англійського словника для інтеграції фінансових технологій - і, що важливіше, як використовувати його в реальних розмовах.
Регулятивний шар: відкрите банківство і PSD2
** Відкритий банкінг ** це практика банків, що обмінюються фінансовими даними клієнтів з уповноваженими третіми сторонами через безпечні API - за згодою клієнта. У Великій Британії, він регулюється Компанією з конкуренції і ринків (CMA) і побудований на стандарті під назвою UK Open Banking Standard.
«Ми інтегруємося з трьома британськими банками через відкритий банкінг. Клієнт авторизує доступ один раз, а потім ми можемо витягнути історію транзакцій до 90 днів»
PSD2 (Payment Services Directive 2) - це регламент Європейського Союзу, який надав право відкритого банку і впровадив жорсткі вимоги до автентифікації клієнта. Навіть після Brexit, правила Великої Британії залишаються тісно узгодженими з PSD2.
«PSD2 змінила гру для постачальників платіжних послуг в Європі. SCA є найбільш видимим впливом для кінцевих користувачів»
** Сильна автентифікація клієнта (SCA) ** — це вимога безпеки, яка означає, що платіж має бути перевірено за допомогою принаймні двох з трьох факторів: чогось, що користувач * знає * (PIN, пароль), чогось, що користувач * має * (телефон, картка), або чогось, що користувачем * є * (біометричні дані).
“Коефіцієнт конвертації знизилася після того, як ми ввімкнули SCA. Нам потрібно подати заявку на виключення з аналізу ризиків транзакцій для платежів малої вартості»
Зауважте, що інженери запрошують винятки, вмикають SCA і запускають поток автентифікації.
Ролі постачальника: AISP і PISP
Дві ролі важливі в відкритих банківських розмовах. ** AISP ** (Account Information Service Provider) має право * читати * дані рахунку — баланси, операції, категорії. PISP (Провайдер послуг ініціювання платежу) має право ініціювати платежі від імені клієнта.
“Ми ліцензовані як AISP, що означає, що ми можемо отримати доступ до даних рахунку, але ми не можемо ініціювати платежі безпосередньо. Для цього нам потрібна ліцензія PISP або партнер PISP»
Ці абревіатури завжди вимовляються в розмовній англійській на технічних викликах. Кажи кожну літеру: “А-І-С-П”, “П-І-С-П”.
** Ініціалізація платежу ** описує дію запуску банківського переказу від імені користувача з сторонньої програми — без необхідності входу користувача у свій банк безпосередньо.
«Ініціалізація платежу дозволяє клієнтам оплачувати безпосередньо зі свого банківського рахунку при оформленні — не потрібно номера карти. Рівень конверсії, як правило, вище»
** Агрегування рахунків ** — це процес об’ єднання даних про операції з декількох банківських рахунків у єдиний перегляд. Це основна функція, яку більшість AISPs будує.
«Наш рівень агрегації рахунків нормалізує дані про транзакції понад 40+ банків в єдину схему»
Технічний словник
** Розрахунок за допомогою Webhook** стосується процесу отримання і обробки сповіщень про стан платежу, надісланих постачальником платіжних послуг за допомогою HTTP webhook. Розрахунок означає, що кошти переведені.
“Ми отримали webhook, але статус розрахунку очікував більше 24 годин. Ми мусили запитати кінцеву точку стану як резервний варіант»
** ключ ідемобільності ** — це унікальний ідентифікатор, який надсилається з запитом, щоб переконатися, що якщо один і той же запит буде надіслано декілька разів (через повторну спробу), оплата буде оброблена лише один раз.
“Всегда включать ключ имемпотенции в запросы на инициирование платежей. Якщо мережа впаде і ми спробуємо знову, ми не хочемо подвоювати плату клієнта»
Це термін, який ви * маєте * знати, як пояснити нетехнічним зацікавленим сторонам: * “Це унікальний ID, який ми приєднуємо до кожного запиту на оплату, щоб система знала, що він вже оброблений, якщо нам доведеться спробувати знову.” *
** Прирівнювання ** — це процес порівняння записів транзакцій у вашій системі з записами банку або постачальника платіжних послуг, щоб переконатися, що вони збігаються.
“Ночью примирение показало три несоответствия. Нам потрібно дослідити, чи є це проблеми з часом або справжніми розбіжностями»
** Chargeback ** відбувається, коли клієнт спростовує транзакцію, а мережа карток скасує платіж, повертаючи кошти клієнту.
«Наша ставка зворотного стягнення зросла цього місяця — вона вище порогу Stripe. Ми повинні затягнути нашу логіку виявлення шахрайства»
** Тестування у піщинному середовищі ** означає тестування у симуляційному середовищі оплати, яке надає банк або постачальник платіжних послуг, за допомогою тестових реквізитів і підроблених даних.
“Вся інтеграційна робота повинна бути виконана в пісочниці спочатку. Не тестуйте проти виробничих облікових записів — ніколи»
Фрази для технічних запитів і оглядів
Використовуйте ці параметри у викликах виявлення інтеграції, переглядах спринтів і обговореннях подій:
- “Ми зараз перебуваємо у фазі піщаного майданчика. Планується перейти на виробничі дані в спринті 12.”
-
- “Наше виключення з SCA стосується операцій менше 30 фунтів. Все вище цього викликає перенаправлення на сторінку авторизації банку.”*
- “Webhook запускається правильно, але наш користувач не підтверджує це — нам потрібно повернути 200 протягом п’ яти секунд.”
-
- « Чи можете ви підтвердити, що ваш API підтримує повторні спроби на кінцевій точці ініціалізації платежу? » *
-
- « Вчора вночі у нас виникла невідповідність у прирівнюванні — виявилося, що це проблема з часовим поясом під час аналізу часових штампів. » *
Ключові слова
| Collocation | Example |
|---|---|
| initiate a payment | ”The PISP initiates a payment directly from the user’s bank.” |
| trigger SCA | ”Payments above the exemption threshold trigger SCA.” |
| run reconciliation | ”We run reconciliation every night at 02:00 UTC.” |
| handle a chargeback | ”The ops team handles chargebacks manually for now.” |
| include an idempotency key | ”Always include an idempotency key on retry logic.” |
| integrate with open banking | ”We integrate with open banking via the UK Open Banking Standard.” |
Practice
Знайти документацію щодо API для справжнього провайдера відкритого банківського обслуговування (Yapily, TrueLayer або Plaid працюють добре). Прочитайте розділ щодо ініціалізації платежу або агрегування рахунків. Напишіть три речення, у яких пояснюється процес розпізнавання для менеджера продукту, який не володіє технічними знаннями — використовуйте * SCA *, * перенаправлення * і * авторизацію * правильно. Потім читайте їх вголос, зосереджуючись на тому, щоб акронім був чітким: “С-К-А”, “П-С-Д-два”.
Науковий напрямок: мовні проблеми та мовні стереотипи
Будьмо чесними - вивчення професійної англійської, особливо в такій швидко розвивається галузі, як фінансові технології, не просто про запам’ятовування визначення. Це про розуміння тонких відмінностей у фразуваннях, які можуть суттєво вплинути на спілкування і співпрацю. Як людина, для якої мова не є рідною, ви можете відчувати певну плутанину у певних термінах або запитах, не через їх буквальний зміст, а через культурний контекст, який вони містять. Наприклад, здавалося б простий запит, як «виправити це» під час перегляду коду може відчувати себе неймовірно вимогливим - це не обов’язково означає фундаментальну помилку, просто щось потребує коригування. Аналогічно, повторювані слова «забезпечити ідемпотентність» можуть звучати абстрактно, поки ви не зрозумієте їх практичні наслідки для управління потенційними помилками в системах обробки платежів.
Поширеною пасткою є припущення, що прямі переклади з вашої рідної мови завжди будуть працювати. Використання надто буквальних фраз в описах Slack або PR може призвести до плутанини і затримок. Уявіть, що ви отримуєте повідомлення на зразок: « Будь ласка, реалізуйте функціональність « відкритого банку » ». Хоча це технічно правильно, але у цьому повідомленні бракує контексту. Кращий підхід був би: «Чи можете ви інтегруватись з API Open Banking, щоб полегшити обмін даними про рахунок згідно з правилами PSD2?» Останнє чітко говорить * що * потрібно зробити - інтеграція з конкретним API - і * чому * - узгодження з нормативними стандартами. Це про передачу намірів, а не просто про технічний термін.
Інша область потенційної плутанини виникає під час обговорень навколо процесів примирення. Фрази на кшталт «зв’язати транзакції» можна інтерпретувати декількома способами. Мы говорим о совпадении идентификаторов транзакций? Скільки? Валюта? Точне формулювання визначає обсяг завдання і впливає на те, скільки часу потрібно на виконання завдання вручну. Більш описова фраза, наприклад, «прирівняти платежі до бухгалтерської книги за допомогою автоматизованих правил», негайно прояснює очікування і зменшує неоднозначність. Створення міцної основи в загальному словнику Fintech не тільки про знання слів; це про розуміння * як * ці слова використовуються для ефективного співробітництва в рамках вашої команди.
Нарешті, пам’ ятайте, що технічна документація часто використовує точну мову, призначену для розробників, але це іноді може здатися надто формальним або навіть залякуванням, коли ви вперше навчаєтесь. Не вагайтеся задати прояснюючі питання - швидке повідомлення Slack на кшталт “Чи можете ви розібратися, що означає “негативне примирення” в цьому контексті?” є цілком прийнятним і демонструє активне залучення.
# Example: Checking for duplicate transactions using the Plaid API (a common Open Banking integration)
plaid_transactions --account_id YOUR_PLAID_ACCOUNT_ID --limit 10 | jq '.'