3 ms·

> Much of US banking operates almost entirely on this premise and has done so forever. I've had the same epiphany when I worked for a fintech startup that inte

> Much of US banking operates almost entirely on this premise and has done so forever. I've had the same epiphany when I worked for a fintech startup that interacts with financial institutions. Having a website just isn't necessary for some of the day-to-day operations vs just sending CSV/Excel files back and forth for reconciliation, settlement, accounting purposes.

AdieuToLogic 1y ago
> Having a website just isn't necessary for some of the day-to-day operations vs just sending CSV/Excel files back and forth for reconciliation, settlement, accounting purposes. This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support.
- immibis 1y ago
  It kind of does. You still have all the same backend logic, but now it doesn't have to run concurrently with a user interface. You can take a queue of operations, process operations off the queue and send their results back. Isn't that a pretty reasonable way for a system to behave? More than a few systems do this internally, with some kind of central message queue.
  - AdieuToLogic 1y ago
    >>> Having a website just isn't necessary for some of the day-to-day operations vs just sending CSV/Excel files back and forth for reconciliation, settlement, accounting purposes. >> This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support. > It kind of does. You still have all the same backend logic, but now it doesn't have to run concurrently with a user interface. Problem is, there is no self-administration capability when a feed file is the sole transaction mechanism. This can work when the volume is relatively small, say a few dozen customers, or if the Merchant is known to be sophisticated enough. > You can take a queue of operations, process operations off the queue and send their results back. Isn't that a pretty reasonable way for a system to behave? Not when there are capability requirements beyond batch processing, such as independent transaction research and/or manual corrections. Both are very common needs with Merchants lacking a dedicated system development department. EDIT: Consider a local bar or food truck which accepts credit/debit/gift card payments. Even if they use host capture and a canonical credit card terminal, the Merchant will certainly want to reconcile their receipts with the end-of-day settlement. This is not functionality "CSV/Excel" files and batch processing interfaces can provide.

AdieuToLogic 1y ago

> Having a website just isn't necessary for some of the day-to-day operations vs just sending CSV/Excel files back and forth for reconciliation, settlement, accounting purposes. This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support.

immibis 1y ago
It kind of does. You still have all the same backend logic, but now it doesn't have to run concurrently with a user interface. You can take a queue of operations, process operations off the queue and send their results back. Isn't that a pretty reasonable way for a system to behave? More than a few systems do this internally, with some kind of central message queue.
- AdieuToLogic 1y ago
  >>> Having a website just isn't necessary for some of the day-to-day operations vs just sending CSV/Excel files back and forth for reconciliation, settlement, accounting purposes. >> This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support. > It kind of does. You still have all the same backend logic, but now it doesn't have to run concurrently with a user interface. Problem is, there is no self-administration capability when a feed file is the sole transaction mechanism. This can work when the volume is relatively small, say a few dozen customers, or if the Merchant is known to be sophisticated enough. > You can take a queue of operations, process operations off the queue and send their results back. Isn't that a pretty reasonable way for a system to behave? Not when there are capability requirements beyond batch processing, such as independent transaction research and/or manual corrections. Both are very common needs with Merchants lacking a dedicated system development department. EDIT: Consider a local bar or food truck which accepts credit/debit/gift card payments. Even if they use host capture and a canonical credit card terminal, the Merchant will certainly want to reconcile their receipts with the end-of-day settlement. This is not functionality "CSV/Excel" files and batch processing interfaces can provide.