In a broader sense, an e-banking application should be able to send your payments to other banks. So a program that sends SWIFT messages can be considered a system program on the server that runs the e-banking application. However, that program will usually be commercially bought, and it can be considered as placed on the system to fulfil a specific, extra, function, so you might well say that it is an add-on, rather than a true system program in the strict sense.
In a more narrow sense, the SSH daemon on the Unix server that runs the e-banking application, is necessary so that administrators may log into the server to see what's up. The network time daemon NNTPD makes sure that the server stays synchronized nicely with the rest of the world. These are typical system programs, though they don't directly 'belong' to the end goal (the e-banking service). Even LS can be considered a system program; what would you do without it?
So the definition of a system program is whatever you make of it. However, system programs will often share some characteristics:
In this series of lectures the focus will be on the two latter points: if you ever need to write a program that runs in the back ground, and that connects via the network, how would you go about it?