В какой-то момент я заметил, что сам учет финансов в Obsidian меня полностью устраивает, а вот сбор исходных данных для него каждый раз отнимает лишнее время.

Схема была простой и довольно утомительной: открыть несколько банков, посмотреть остатки по счетам и картам, потом перенести эти цифры в свои заметки. По отдельности это мелочь, но в регулярной рутине такие действия быстро начинают раздражать.

Я решил автоматизировать именно этот участок. Мне был нужен локальный и понятный способ собирать данные из интернет-банков, а уже потом использовать их в своей системе заметок.

В этой части речь пойдет именно про сбор данных: как я сделал небольшой bridge-слой между банками и Obsidian. Во второй части можно будет уже перейти к тому, как эти данные встраиваются в vault.

Что именно я хотел получить

У задачи было несколько практических требований:

• запуск одной короткой командой

• работа с уже авторизованными банковскими сессиями

• минимум ручных действий в повседневном использовании

• хранение чувствительных данных только локально

• результат в нормальном машиночитаемом виде, который дальше удобно использовать в Obsidian

Почему я выбрал путь через браузер

Сначала была идея заюзать готовую апишку банков. Я начал читать про AlphaAPI, но быстро понял, что апи скорее расчитана на бизнесовые интеграции и технологическое сотрудничество.

Подписывать договор о технической интеграции с банком ради простой автоматизации личного ведения финансов мне не очень хотелось, поэтому я решил пойти другим путем.

Мне пришла идея просто распарсить веб страничку банка. Просто, сердито и на первый взгляд безопасно.

В результате проект работает через Chrome DevTools Protocol. Скрипт открывает нужную страницу банка в выделенном профиле, подключается к вкладке и считывает нужные данные со страницы.

Что делает проект

Сейчас проект умеет работать с тремя банками:

• Альфа-Банк

• ВТБ

• Т-Банк

Он:

• запускает отдельные persistent-профили Chrome для каждого банка

• открывает нужные страницы

• ждет ручную авторизацию, если сессия истекла

• извлекает балансы по счетам и картам

• для кредитных карт дополнительно собирает долг, доступный остаток, лимит и даты платежей, если банк показывает эти поля

• сохраняет результат в локальный JSON вне репозитория

Основной пользовательский вход выглядит так:

bankscan

Или, если вызывать напрямую:

node scripts/bank-balance-bridge.mjs sync all

Под капотом это обычный локальный CLI-скрипт. Никаких внешних сервисов в этой части нет.

Как это выглядит в ручном сценарии

Первый запуск такой:

node scripts/bank-balance-bridge.mjs open all

Скрипт открывает окна Chrome с выделенными профилями для банков. Дальше я один раз прохожу авторизацию в этих окнах.

После этого в обычной жизни достаточно запускать:

bankscan

Если банковские сессии еще живы, скрипт быстро проходит по ним и обновляет сводку. Если где-то нужна повторная авторизация, он открывает нужное окно и ждет завершения входа. После этого тот же самый запуск продолжает работу сам. Дополнительную команду вручную запускать уже не нужно.

Для меня это было важной частью удобства. Если автоматизация требует лишней координации, ей быстро перестаешь пользоваться.

Почему понадобились отдельные профили Chrome

С обычным пользовательским профилем Chrome такой проект жить не должен. Здесь сразу возникают и технические, и организационные проблемы.

Я выбрал отдельные bridge-профили для каждого банка. У этого решения есть несколько плюсов:

• банковские сессии изолированы от основного браузера

• в окнах для автоматизации нет обычного пользовательского шума

• сессии можно переиспользовать между запусками

• поведение становится стабильнее и предсказуемее

Отдельно всплыл еще один практический момент: начиная с Chrome 136, стандартный user data dir плохо подходит для remote debugging в таком сценарии. Так что выделенные профили в итоге оказались еще и самым рабочим вариантом с технической точки зрения.

Где хранится результат

Реальные данные я принципиально не держу в репозитории. Все runtime-файлы лежат в локальной директории состояния.

Основной итоговый файл такой:

~/.codex/state/bank-balance-bridge/balances-summary.json

Рядом сохраняются и сырые результаты отдельных сканов по банкам. Они помогают, когда нужно понять, что именно поменялось на стороне сайта и почему extraction внезапно перестал совпадать с ожидаемой структурой.

Такой подход оказался удобным сразу по нескольким причинам:

• в git не попадают реальные суммы и чувствительные данные;

• основной JSON можно использовать как стабильную точку интеграции;

• отладка идет по локальным файлам, без догадок «что там мог увидеть браузер».

Что в итоге попадает в summary

У сводного файла довольно простая структура. По каждому банку есть статус, служебная информация и списки найденных продуктов.

В упрощенном виде это выглядит так (все суммы выдуманы):

{
  "updatedAt": "2026-04-20T08:15:12.000Z",
  "banks": {
    "alpha": {
      "bankId": "alpha",
      "bankName": "Альфа-Банк",
      "status": "ok",
      "balances": [
        {
          "kind": "account",
          "label": "Альфа-Счет",
          "accountMask": "1234",
          "amountText": "154 200,31 ₽",
          "amountValue": 154200.31,
          "currency": "RUB"
        }
      ],
      "creditCards": []
    },
    "tbank": {
      "bankId": "tbank",
      "bankName": "Т-Банк",
      "status": "ok",
      "balances": [],
      "creditCards": [
        {
          "label": "Platinum",
          "linkedCardMasks": ["4321"],
          "debtAmountText": "18 450,00 ₽",
          "availableAmountText": "81 550,00 ₽",
          "creditLimitText": "100 000,00 ₽",
          "paymentDueDateText": "до 25 апреля",
          "gracePeriodUntilText": "12 мая"
        }
      ]
    }
  }
}

Этого уже достаточно, чтобы потом читать данные из любого локального скрипта, шаблона или плагина, который работает с файлами.

Пример обычного запуска

В консоли результат выглядит примерно так (все суммы выдуманы):

alpha: ok - Dedicated bridge profile is ready for Альфа-Банк
  - [account] Альфа-Счет ··1234: 154 200,31 ₽

vtb: ok - Dedicated bridge profile is ready for ВТБ
  - [account] Мастер-счет ··5678: 42 018,90 ₽

tbank: ok - Dedicated bridge profile is ready for Т-Банк
  - [credit_card] Platinum ··4321: долг 18 450,00 ₽, доступно 81 550,00 ₽, лимит 100 000,00 ₽, платёж до 25 апреля, без % до 12 мая

Для повседневной задачи этого более чем хватает: я запускаю одну команду и получаю локальный источник правды по текущим остаткам.

Что оказалось самым хрупким местом

Самая сложная часть здесь связана не со скриптом как таковым, а с тем, что каждый банк устроен по-своему.

У Альфа-Банка основной источник данных — dashboard, и в этом смысле сценарий довольно прямой.

У ВТБ есть чувствительность к лишним переходам и перезагрузкам страницы. Если обращаться с этим слишком агрессивно, можно легко прилететь в logout и получить лишний цикл авторизации.

У Т-Банка важно корректно различать основной экран интернет-банка и промежуточные auth/setup-страницы. Иначе можно принять переходный экран за отсутствие данных.

Из-за этого проект пришлось делать довольно приземленным: без “универсального движка для любых банков”, зато с явной логикой для каждого поддерживаемого сценария.

Почему это вообще связано с Obsidian

На этом этапе связь с Obsidian довольно простая.

В Obsidian'e у меня второй мозг. Вы найдете миллион статей и видосов на ютубе, об этом, в этой статье углубляться в это не буду. В том числе в своем волте я веду финансовый учет.

После запуска bankscan у меня появляется актуальный balances-summary.json. Дальше уже можно использовать его внутри vault так, как удобно в конкретной системе: хоть через шаблоны, хоть через Dataview, хоть через внешние скрипты, которые обновляют заметки.

Зачем позже я оформил это в skill для Codex

Когда ручной сценарий уже устоялся, стало понятно, что поверх него можно добавить еще один удобный слой.

Я оформил проект в локальный skill для Codex, чтобы агент работал по предсказуемому сценарию:

• запускал bankscan как основной entrypoint;

• ждал ручную авторизацию, если она нужна;

• дочитывал результат из локального balances-summary.json;

• отдельно учитывал блок creditCards, где лежат расширенные данные по кредиткам;

• не просил у меня логины, коды, cookies и прочие чувствительные вещи.

Для меня это решает практическую задачу: Codex получает четкий и детерминированный путь работы с финансовыми данными, а не начинает каждый раз импровизировать вокруг браузера и банковских страниц.

Важно, что в основе здесь все равно остается обычный локальный скрипт. Skill просто делает этот процесс удобнее для агентного сценария.

Итог

Теперь я могу могу попросить codex, как своего личного ассистента, детерминированно собрать мне всю инфу с банков.

Что делать с этой инфой? Да что душе угодно. Можно попросить агента каждое утро собирать информацию о деньгах и вести учет, можно делать еженедельные и ежемесячные анализы, строить графики и чувствовать, будто у вас все под контролем :-)

На случай, если захотите попробовать, выложил все на гитхаб: BankScan