Как юзающий БК (от BSS) на обоих сторонах, вот мои соображения:
1) В настоящее время в БК используется только платежное поручение. С валютой лучше не заморачиваться.
2) Cправочники на стороне клиента (кроме его личных - напр. справочник корреспондентов) должны обновляться из банка. Каждый год какие-то изменения - особенно касающиеся налогов (т.е. бюджетная классификация, статусы составителя и пр.). Также справочник банков - тот еженедельно обновляется. Причем справочник банков должен обновляться не целиком, а частично - полный его размер в DBF более мегабайта, а пересылать желательно только новые/измененные/удаленные записи.
3) То же касается визуальных и печатных форм, а также структур таблиц. Должно быть предусмотрено удаленное обновление. Запросто завтра могут добавить новое поле.
4) из п.2-3 следует, что клиент должен представлять собой модульную структуру, чтобы при передаче изменений можно было менять только отдельные компоненты (DLL и отдельные файлы), а не всю инсталляцию целиком: по модему вытягивать мегабайтные файлы все же тяжко. Причем для непрерывности процесса в банке должна быть поддержка нескольких версий одновременно.
5) система на стороне клиента должна иметь легкую связь с распространенными бух.программами - например, в 1С встроена поддержка популярных Б\К. Нужно ориентироваться на эти форматы.
Соответственно, в банке - выгрузка в формате, понимаемом АБС, и обработка выписок, формируемых из АБС.
6) Должна быть
гарантированная доставка выписок от банка и платежек в банк: если связь прервалась, комп повис и пр. Т.е. на каждую отосланную в любую сторону информацию должно быть подтверждение или явный отказ. Если подтверждения в течении определенного времени нет, то автоматический повтор передачи. Особенно это касается
интернет-банкинга. При этом ЭЦП подписывается файл с платежкой, непосредственно передаваемый в Банк.
7) Клиент должен видеть состояние своего документа после каждой операции - например, "подписан", "отправляется", "отправлен", "принят банком" ("не принят", "Ошибка ЭЦП"), "проведен/исполнен" когда этот док попадает в выписку, или "не исполнен", "ошибка" с диагностикой, понятной клиенту. Также везде должен быть timestamp каждой операции (когда клиент ввел документ, когда отправил, когда обработан банком, когда сформирована выписка)
8) Очень жесткий контроль вводимой информации. Все что можно - проверять по справочникам и через алгоритмы (банки, счета, ИНН, и пр.) Причем контроль может быть "жестким" (т.е. вообще не давать записывать платежку в случае серьезных ошибок - напр. банк не найден), и мягким (предупреждение - напр. неверный код бюджетной классификации - может, он и правильный, но в справочнике его нет).
9) Должен быть удобный поиск при вводе значений из справочников. Например, выбирать банк из 10000 записей перелистыванием - не фонтан. То же - из справочника корреспондентов (в BSS, например, предусмотрен быстрый поиск по имени, ИНН, расчетному счету).
10) ПО не должно быть "привязано" к клиенту. На одном ПО может быть несколько разных организаций, а к одной организации может быть привязано несколько счетов (как активных, так и пассивных). Бывает также, что ПО должно быть установлено в разных местах - например, в бухгалтерии и на ноутбуке директора. Следовательно, формируемые выписки должны идти в разные направления.
[11] Желательно разграничение прав пользователей. Например, у одного есть право подписи, другой может только смотреть выписки. Для крупных клиентов актуальна работа в сети.
За основу структуры информации, содержащейся в платежных документах, их возможные значения лучше смотреть тут:
Унифицированные форматы электронных банковских сообщений для безналичных расчетов. Исхдя из этого ты уже можешь прикинуть, какие поля будут в таблицах. Передавать в Банк сообщения в формате XML не обязательно, т.к. с ними проблематично работать, хотя в смысле унификации - неплохо.
Насчет системы связи - она может быть любая. Например, BSS может поддерживать такие виды передачи информации: 1) файлы 2) через e-mail 3) напрямую через TCP/IP (т.е. сервер БК в банке служит TCP-сервером)
В общем случае ПО и его интерфейс на стороне банка и клиента почти одинаковое, но в Банке есть дополнительные функции.
Выбор БД - на последнем месте. Например, в BSS у клиента используется MS Access (в банке - Sybase/Oracle), у других - Interbase, у третьих FoxPro.
Круто. Софт этот пишется всеже под ОД(банковская часть), который в свою очередь стоит на базе. Это стороннему разработчику фиолетово, написал, а потом банковские ИТ спецы думайте как результат подцеплять да к ОД прикручивать. 
АРМ операциониста, извини, уже не Клиент-Банк.