akurash

Я рекомендую посмотреть в сторону EAV. Но!!! Смотреть очень внимательно. Там есть очень большая куча плюшек и примерно такая же куча ....хм.... не плюшек. Выбирать только вам.
И добавлю сюда ссылку на очень похожее обсуждение:
Как хранить абстрактные модели данных в реляционных БД?

Кстати, постарайтесь почёте сформулировать ваш вопрос. Возможно, если этих самый неизвестных параметров будет немного - то лучшим способом будет простое расширение табличек.
В сторону EAV надо смотреть если у вас количество и сами параметры могут сильно отличаться от объекта к объекту. И сами эти параметры могут появляться стихийно по желанию ваших пользователей.
Так же очень рекомендую рассмотреть компромиссный вариант, в котором у вас будет использоваться классическая структура полей и таблиц. И где-то рядом к ней будет пристёгнута структура EAV для экспериментов с полями. В этом случае основная нагрузка будет на классические структуры а все эксперименты с дополнительными полями будут по сути отдельно.
В случае если какое-то из экспериментальных дополнительных полей в последствии станет очень нужным и всем необходимым - то никто не мешает зарефакторить структуру БД и перенести это поле в основные таблицы....

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